SanseoLab

0. 개요

1. PE의 특징

2. Manual Extracting

0. 개요

VBScript

Scripting Engine [VBScript.dll] not registered

Scripting Engine [VBScript.dll] not started

Scripting Engine Parser not available

Could not host scripting site

...

  악성코드를 분석하다 보면 위와 같은 문자열들을 가진 바이너리를 볼 수 있다. 내용을 보고 추측해 봤을 때 AutoIt이나 AutoHotKey 등 처럼 VBScript를 컴파일하여 바이너리 형태로 변환한 것이라는 생각이 들어 더 찾아보게 되었다.

  이것들은 대부분의 경우 VbsEdit [ http://www.vbsedit.com ] 이라는 VBS 에디터 프로그램의 추가 기능을 이용한 방식으로 생성된 것으로 보인다. 이 기능은 내부적으로 script2exe라는 프로그램을 사용한다.

  생성 주체는 찾았고 이제 AutoIt 처럼 스크립트를 추출할 수 있는 방법을 알아내던 중 다음 링크를 찾을 수 있었다. 첫 번째 링크는 이렇게 만들어진 PE의 특징부터 디컴파일하는 과정에 대해 정리된 글이며, 두 번째 링크는 이 과정 즉 스크립트 추출을 자동화해 주는 IDA Pro 파이썬 스크립트이다.

[ https://www.politoinc.com/single-post/2017/11/03/Unpacking-script2exe-Malware ]

[ https://github.com/PolitoInc/script2exe_dumper ]

  하지만 직접 사용했을 때 특정 분기문에서 이 스크립트가 전제로 하는 부분이 실행되지 않아 항상 결과를 반환하지는 않는다는 것을 확인하였다. 또한 IDA Pro가 필요하며 디버깅을 전제로 하기 때문에 동적으로 실행될 위험이 존재한다는 단점도 있다. 물론 어쩔 수 없는 경우라면 이 스크립트를 수정하여 처리해야 하겠지만 뒤에서 살펴보듯이 RC4 암호화에 사용되는 키가 항상 같다는 특징을 이용해서 충분히 자동화 스크립트를 제작할 수 있다.

  여기에서는 차례대로 생성된 PE의 특징과 직접 스크립트를 추출하는 방식을 설명한다. 자동화 스크립트 개발 시 개인적으로 사용했던 부분들도 중간 중간에 들어갈 것이다.

1. PE의 특징

  Resource Hacker나 PEview 등의 도구를 통해 리소스 섹션 내부에 129번 (0x81) "Bitmap" 타입이 포함되어 있는 것을 확인할 수 있다. 이것은 VBS가 RC4 암호화 알고리즘으로 인코딩되어 저장된 것이다.

  이 특징은 자동화에 쉽게 사용될 수 있는데 해당 Bitmap을 PE 섹션에서 찾아서 추출하는 스크립트를 짤 수도 있을 것이고, 더 간단하게 7zip 같은 압축 프로그램을 이용해 PE 압축 해제 시 결과로 받는 129.bmp 파일을 이용할 수도 있다. 물론 매뉴얼하게 Resource Hacker를 이용해 해당 부분을 추출할 수도 있다. 참고로 리소스 섹션에 위치하던 Bitmap 파일로 존재하던 두 형태에 대한 구조를 알아야 크기 및 오프셋을 확인하고 추출할 수 있다.

  다음 특징으로 pdb 문자열이 있다. 최신 버전에서는 이것을 확인할 수 없지만 과거 버전에서는 변환 시 다음과 같은 문자열이 pdb 관련해 항상 PE에 저장되었던 것으로 추정된다.

"C:\\Projets\\vbsedit_source\\script2exe\\Release\\mywscript.pdb"

2. Manual Extracting

  RC4 암호화 알고리즘으로 인코딩된 데이터는 확인하였으니 이제 키 값만 구하면 해당 스크립트를 완벽하게 추출할 수 있다. 위의 참고 자료를 보면 IDA Pro 파이썬 스크립트를 사용하여 키 값을 구할 때까지 디버깅을 진행한 후 이 키를 이용해 복호화를 진행하는 방식을 사용한다.

  정확히는 IDA Pro를 이용해 "_rand" 함수를 구하고 이 함수를 참조하는 루틴을 찾았을 때 ( Cross Reference ) 특정 루프문을 볼 수 있다. 이것은 바이트 연산 후 저장하는 행위를 반복하여 결국 0x20 크기의 키를 생성하는 역할을 한다. 이 루프문이 끝나면 저장된 버퍼에서 0x20 크기의 키를 획득할 수 있다.

  문제는 현재 구할 수 있는 이 VbsEdit 프로그램은 모두 같은 RC4 키를 사용한다는 점이다. 이를 통해 디컴파일 과정을 디버깅 필요 없이 간단하게 진행할 수 있다. 먼저 PE에서 인코딩된 VBScript를 추출한 후 다음의 RC4 키를 이용하는 복호화 알고리즘을 사용하면 된다.

[ AgyUouKrxGu0q4lFjxxbWR4agvL7xFR0 ]

  참고로 RC4 알고리즘의 경우 파이썬으로도 많이 나와 있지만 문제는 스트링에 대한 것들이 대부분이고 파일을 대상으로 하는 코드는 찾기 힘든 편이다. 스트링을 대상으로 하는 코드를 사용하면 0x00 같은 값을 인식하지 못해 이 부분까지만 복호화가 진행된다. 그래서 개인적으로 참조했던 오픈 소스를 여기에 올리기로 한다.

[ https://github.com/g2jun/RC4-Python ]

  Autoit은 스크립트 언어이지만 aut2exe.exe라는 변환기를 이용해 쉽게 exe 실행 파일로 변환할 수 있다. 대신 디컴파일로 간단한데 exe2aut.exe라는 디컴파일러를 통해 쉽게 autoit 스크립트 소스 코드를 얻을 수 있다. 만약 이 실행 파일에 또 다른 파일이 (악성코드의 경우 대부분 바이너리) 포함되어 있다면 그것도 드랍해 준다.

  이렇게 디컴파일이 가능하고 문법 자체도 그렇게 어렵지 않기 때문에 처음 본 경우라도 쉽게 분석할 수 있다. 하지만 분석하다 보면 트릭을 사용하거나 해서 이해하기 힘든 부분이 존재하는데 여기에서는 그러한 내용들을 다루려고 한다.

1. FileInstall() 함수

  FileInstall() 함수는 실행 파일로 변환 시 특정 파일을 포함할 수 있고 실행 시에는 드랍할 수 있는 기능을 가진 함수이다. 문제는 이것이 설명만 보아서는 이해하기 힘든 내용이라는 점이다. 물론 원래 이러한 기능을 생각한 것은 아니었지만 일종의 트릭이 되어서일 수도 있다.

FileInstall("PEview.exe", @TempDir & "\PEview.exe",1)

Run(@ComSpec & " /c " & @TempDir & "\PEview.exe", "", @SW_HIDE)

  위와 같은 내용의 .au3 소스 코드를 만든다. 이후 Aut2Exe를 이용해 .au3 소스 코드를 .exe 실행 파일로 변환한다. 이 때 소스 코드와 같은 디렉터리에 PEview.exe를 같이 두어야 한다. (FileInstall() 함수 첫 번째 인자의 경로가 현재 디렉터리이므로) 그러면 실행 파일로 변환될 때 PEview.exe가 실행 파일에 같이 통합된다.

  이제 이 실행 파일을 실행시키면 FileInstall() 함수의 두 번째 인자인 Tmp 디렉터리에 PEview.exe가 추출되어 위치하며 이후의 Run() 함수를 통해 그곳에서 실행된다. 즉 FileInstall() 함수의 첫 번째 인자는 바이너리에 통합할 실행 파일이며 두 번째 인자는 나중에 실행 시에 통합된 실행 파일이 추출될 위치이다.

2. 셸코드

  Autoit 스크립트 내에서 트릭을 이용해 직접 셸코드를 실행시킬 수도 있다. 다음은 그 예제인데 DllStructCreate()를 이용해 구조체를 생성하고 DllStructSetData()로 셸코드를 설정한 후 DllStructGetPtr() 해당 셸코드의 주소를 얻어온 후 DllCallAddress()로 실행시키는 방식이다. 이후 DllStructGetData()로 반환 값을 얻어와서 스크립트에서 그 결과를 사용할 수도 있다.

[ https://www.autoitscript.com/forum/topic/192706-extended-cpuid-x86-x64/ ]

3. 관리자 권한을 가진 바이너리

  프로그램이 관리자 권한을 가지고 실행되는 속성을 가진 경우가 있다. Windows Vista 이후부터는 아이콘에 추가적인 그림이 표시되기 때문에 쉽게 확인할 수 있을 것이다. 정확히는 리소스 섹션의 Manifest 부분을 통해 다음을 확인할 수 있다.

<security>

  <requestedPrivileges>

    <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>

  </requestedPrivileges>

</security>

  이러한 경우는 해당 바이너리를 디컴파일하기 위해 exe2aut에 드래그 앤 드랍으로 끌어놓으면 exe2aut가 "Couldn't invoke the file!"이라는 메시지를 내보내는 것을 볼 수 있다. exe2aut는 일반 사용자 권한으로 실행되었기 때문에 관리자 권한으로 실행되는 프로그램을 다룰 수 없기 때문이다. 만약 exe2aut를 관리자 권한으로 실행시킨다면 드래그 앤 드랍 방식이 통하지 않는다. cmd를 관리자 권한으로 실행시킨 후 파일을 끌어다 놓는 드래그 앤 드랍 방식이 통하지 않았던 것을 보면 윈도우에서는 기본적으로 이러는 것 같다.

  문제는 exe2aut는 드래그 앤 드랍 방식 말고 커맨드 라인 방식으로 인자를 받거나 하지 않기 때문에 일반 사용자 권한으로는 관리자 권한인 바이너리를 다룰 수 없고 관리자 권한으로는 드래그 앤 드랍이 되지 않아서 삽질을 많이 했다.

  결론만 이야기하자면 이 경우에는 간단하게 관리자 권한 메커니즘 즉 Integrity Level이 존재하지 않는 Windows XP에서 작업하면 된다.

  또는 아래의 x64 바이너리를 디컴파일하는 방법에서 설명된 방식을 사용할 수 있다. 간략하게 설명하자면 컴파일된 소스 코드를 추출하여 빈 바이너리에 덧붙인 후 이것을 exe2aut에 올려서 디컴파일하는 방식이다.

4. x64 바이너리 디컴파일

  Exe2aut는 x64 바이너리를 지원하지 않지만 트릭을 사용하면 x86과 마찬가지로 쉽게 디컴파일이 가능하다. 바로 위에서 간략하게 설명하였듯이 준비물은 AutoIt이 스크립트 파일을 exe 파일로 변환하는데 사용하는 dumb 바이너리와, 컴파일된 소스 코드가 필요하다. 빈 바이너리는 설치 폴더에서 찾을 수 있으며 컴파일된 소스 코드 부분은 아래의 방식처럼 쉽게 바이너리 검색으로 찾을 수 있다.

  이것은 다음의 링크에서 참조한 내용이며 여기서는 간략하게 방식만 설명한다.

[ http://www.hexacorn.com/blog/2015/01/08/decompiling-compiled-autoit-scripts-64-bit-take-two/ ]

  먼저 x64 버전의 AutoIt 바이너리에서 컴파일된 소스 코드를 추출한다. 컴파일된 소스 코드는 다음 값으로 시작한다.

=> Hex : A3 48 4B BE 98 6C 4A A9 99 4C 53 0A 86 D6 48 7D41 55 33 21 45 41 30 36 4D ...

=> Text : £HK¾˜lJ©™LS†ÖH}AU3!EA06M ...

  그리고 여기부터 시작해서 다음 값으로 끝난다.

=> Hex : ... 41 55 33 21 45 41 30 36

=> Text : ... AU3!EA06

  저 시작 부분부터 끝 부분까지를 저장해 놓자.

  이후 AutoIt을 설치하고 해당 설치 폴더에서 Exe2Aut 폴더에 들어간다. 그러면 [ AutoItSC.bin ]이라는 파일을 찾을 수 있다. 이 파일을 열어서 파일의 마지막 부분에 앞에서 저장했던 컴파일된 소스 코드를 덧붙이고 저장한다. 이렇게 간단히 모든 과정이 끝나고 이제 저장된 바이너리를 Exe2aut에 올리면 정상적으로 디컴파일된 것을 확인할 수 있다.