[Exploit Kit] “AnglerEK”는 왜 Fileless 일까?

 
Angler EK가 사용하는 대표적인 취약점 2가지

• IE / CVE-2014-6332 (God Mode)
  
• SWF / CVE-2014-0515
  

이 중에, “God Mode”로 알려진 CVE-2014-6332 취약점 페이로드(쉘코드)를 통해 알아보자.
 

 

Angler EK가 사용하는 CVE-2014-6332 관련 스크립트

= 자바스크립트 + VB 스크립트

[그림] Angler EK 랜딩페이지 일부

 
VB 스크립트 안에서, 취약점 발생과 실행할 페이로드가 구성된다.
 

메모리에 올라갈 전체 페이로드 =

[NOP Sled] +[ShellCode + 다운로드 URL 주소 + 복호화키 + ShellCode] +[NOP Sled]

 

 
특히, 자바스크립트 안에 있는 sub 함수 “V72dmg3ve7()”는 쉘코드 내부에 들어갈 다운로드 URL 주소와 복호화키를 조합해주는 역할을 수행한다.

 

다운로드 URL = http:// + window.location.host + 정보 Array(또는 변수)

(예: hxxp://xxxx.xxxxxxx.org/UX7n1YkbNn8FUV6QVtEZLj-p-gLvRKlWEWmz3r7Ug8suRiY_)

 

1. Window.location.host : 랜딩페이지의 서버주소
   
2. 정보 Array(또는 변수) : 랜딩페이지에 정의된 Array 데이터를 디코딩 함수(스크립트 내부에 존재)를 통해 디코딩한 후, 다시 Base64 디코딩한 데이터.
   

– 디코딩 함수 결과 : VVg3bjFZa2JObjhGVVY2UVZ0RVpMai1wLWdMdlJLbFdFV216M3I3VWc4c3VSaVlf

– base64 디코딩 결과 : UX7n1YkbNn8FUV6QVtEZLj-p-gLvRKlWEWmz3r7Ug8suRiY_

 
실제 쉘코드가 실행되면 winhttp.dll 상의 함수들을 이용하여 추가적인 데이터를 다운로드 한다.
 

[그림] winhttp.dll 함수들

[그림] 다운로드 응답 데이터

 

다운로드 받은 데이터는 8바이트씩 읽어서  복호화 한다.

 
 

[그림] 복호화 함수 내부

 
데이터 복호화가 진행되는 과정에서 다운로드 받은 임의의 데이터는 실행파일(“MZ”)로 변환된다.
 

[그림] 복호화 전/후 데이터

 

복호화가 모두 완료되면, 첫 4바이트(=Size) 뒤 2바이트가 “9090” 또는 “MZ” 인지 비교한다.

 
분석용 페이로드처럼 복호화 결과가 “MZ”인 경우, %TEMP% 폴더에 임시파일로 드랍(Drop)한 후,
 

 
직접 실행하거나 “regsvr32 /s”를 이용해서 로드(DLL) 한다.
 


 
물론, 페이로드가 “MZ” 인 경우는 로컬 상에 파일을 생성하기 때문에 “Fileless”가 아니다.
 
하지만, 페이로드가 “9090”으로 시작하는 경우, 아래와 같이 페이로드가 존재하는 메모리의 주소를 호출(call)하도록 되어 있다.

따라서, 9090(NOP) 코드 뒤에 앞서 실행파일의 행위코드(랜섬웨어)를 그대로 가지고 있다면, 파일을 로컬에 생성하지 않고 메모리 상에서 바로 실행하는 구조이기 때문에 “Fileless” 가 된다.
(단, 아직 해당 페이로드 형태는 직접 확인하지 못함 ㅠ_ㅠ)
 

[참고]
https://blog.malwarebytes.org/exploits-2/2014/09/fileless-infections-from-exploit-kit-an-overview/
http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html