NSIS 설치파일 형태의 악성코드에서 사용중인 탐지 우회기법

악성코드 제작자는 백신사로부터 진단되지 않기 위해 다양한 시도를 해왔다. 과거에는 분석하기 어렵게 안티 디버깅 기법을 사용하거나 혹은 안티 VM 기법의 비중이 높았다면 지금은 SandBox를 우회하기 위해 시간 지연 방법 등을 사용한다. 이 글에서 소개될 NSIS(Nullsoft Scriptable Install System)는 윈도우용 인스톨 도구로 스크립트 기반으로 동작하기 때문에 외형이 특성상 정상 NSIS 인스톨러와 동일할 수 밖에 없으며, 특이한 점은 스크립트 내부에 시간 지연 코드가 있다는 점과 복호화된 쉘코드 내부에 SandBox를 우회하기 위한 유저 모드 후킹 우회 기법 등이 사용된다는 점이다. 이후 악성행위는 정상 프로세스에 인젝션하여 동작한다.

 

1. NSIS

 

NSIS는 7zip(v15.05 이하)을 이용해 압축을 해제 시 내부 파일 및 스크립트를 확인할 수 있어 아래 [그림 1]과 같이 확인할 수 있다.

 

1-1.         내부 파일

[ 그림  1.] NSIS  내부 추출 결과

악성 행위와 연관된 샘플은 빨간색 테두리로 표시한 3개의 파일이며, 해당 파일에 대한 자세한 내용은 아래 본문에서 설명한다. 추출한 결과로 보았을 때 과거와 현재의 차이점은 정상 파일로 속이기 위해 무의미한 파일들을 내포 시켰다는 것과 "system.dll"이 사라졌다는 것이다.

 

1-2. NSIS 스크립트

 

스크립트 코드는 크게 시간 지연 코드와 실행 방법 2가지로 나뉜다.

 

- 시간 지연 코드

[ 그림  2] NSIS  스크립트  –  시간 지연 코드

과거와 동일하게 현재도 시간 지연 코드를 가지고 있다. 위 [그림 2]의 하단 샘플로 예시를 들자면 디렉토리나 레지스트리 키에 접근하는 무의미한 행위를 $R7이 0이 될 때까지 32,998번을 반복 후 악성코드에 필요한 파일을 생성한다.

 

- 실행 방법

 

[ 그림  3.] NSIS  스크립트  –  파일 생성 및 실행 코드

과거에는 CallInstDLL(system.dll의 call)을 이용해 악성 DLL의 Export 함수를 실행하는 반면 최근에는 ExecWait을 통해 특정 실행 파일(varicella.exe)을 실행한다. 이 "varicella.exe"는 악성 DLL(ChiliadWoodshed.dll)의 Export 함수를 실행하는 용도로 즉, 로더 역할이었던 "System.dll"이 "varicella.exe"로 바뀐 샘이다. 참고로 "varicella.exe"의 파일명은 악성샘플마다 다양한 형태로 변경되어 배포 중이다.

 

2. 내부 쉘코드 행위

 

[ 그림  4.] NSIS 에서 추출된 내부 파일 중 사용되는  3 개의 악성 파일

 

"varicella.exe"를 통해 악성 DLL의 Export 함수를 실행하면 바이너리 파일(파일명: Poundal)을 읽어온다. 이 바이너리 파일엔 압축된 쉘코드가 존재하며, DLL은 RtlDecompressBuffer API를 이용해 쉘코드를 복호화한다. 실제로는 여러 번의 복호화 단계를 거치지만 이 부분에 대한 설명은 생략한다. 참고로 로드되는 바이너리(Poundal) 또한 샘플마다 다르다.

 

[ 그림  5.] RtlDecompressBuffer API

 

2-1. 시간 지연 코드

 

[ 그림  6.]  쉘코드 내부의  2 번째 시간 지연 코드

복호화된 쉘코드 내부에도 시간 지연 코드가 존재한다. 해당 코드는 WriteProfileStringA API를 이용해 %WINDIR%win.ini파일에 10,000번 접근하는 것으로 WriteProfileStringA API는 프로세스가 관리자 권한 이상인 경우에만 win.ini에 접근할 수 있기 때문에 일반적인 사용자 PC에서는 시간 지연은 미비하다.

 

[ 그림  7] WriteProfileStringA API을 이용한 win.ini 접근

그러나 SandBox 환경에서는 사용자 PC와 다르게 시간이 더 지연되는데, SandBox 환경에서는 분석할 샘플을 관리자 권한으로 실행하는 경우가 많아 win.ini에 접근할 수 있다는 것과 프로세스 행위에 대해 로깅하기 때문에 시간 지연이 발생한다.

 

2-2. 유저모드 후킹 우회 기법

 

해당 기법은 과거와 동일한 기법을 사용한다. ntdll을 프로세스에 메모리 상에 다시 로드한 후 기존에 로드된 ntdll이 아닌 새로 로드된 ntdll의 API를 사용하는 방식으로 기존 ntdll에 후킹되어 있는 api를 사용하지 않기 때문에 ntdll 후킹을 이용해 로깅하는 Sandbox에서는 행위를 기록할 수 없다.

 

[ 그림 8.] ntdll 비교 사진 - (좌)새로 읽어온 ntdll / (우)기존 ntdll

위의 과정에서 사용된 API 리스트 및 주요 인자 값들이다.

 

• kernel32.CreateFileW()  - ntdll.dll 핸들 획득
• kernel32.CreateFileMappingW()
• kernel32.MapViewOfFile()

 

(해당 기법의 대한 자세한 설명은 ASEC Report Vol.97에서 소개되어 있다.)
https://www.ahnlab.com/kr/site/securityinfo/asec/asecReportView.do

ASEC Report | AhnLab

 

2-3. 공유 메모리 인젝션 기법

 

마지막으로 쉘코드에 풀어낸 실제 악성코드는 정상 프로세스에 인젝션하여 동작한다. 쉘코드는 악성코드가 .NET으로 컴파일된 경우라면 MSBuild.exe를, .NET 이외의 다른 컴파일 언어로 만들어진 악성코드는 CMD.exe를 실행해 인젝션한다. 아래는 인젝션 기법을 대략적으로 설명하기 위한 Pseudo Code이다.

 

1. hProc = CreateProcessW {.., MSBuild.exe(or CMD.exe),..}: MSBuild를 CreateProccessW로 SUSPEND시켜 실행
2. NtGetContextThread {..,hProc ,..}: MSBuild의 PEB를 구하기
3. hSec = NtCreateSection{.., MAP_EXECUTE|MAP_WRITE, 0, size:{인젝션할 PE의 크기}, PAGE_EXECUTE_READWRITE, SEC_COMMIT }: 공유 메모리 핸들 생성. 크기는 인젝션할 PE크기와 유사
4. NtMapViewOfSection{ hSec, (myself), //현 프로세스 (out_)sec_addr1,..}
5. NtMapViewOfSection{ hSec, hProc, //MSBuild.exe 프로세스 (out_)sec_addr2,..}: 만든 공유 섹션을 각 프로세스에 매핑해 (out 버퍼인)각각의 주소를 가져온다.
6. Memcpy {sec_addr1, inject_PE_addr, size}: 현재 프로세스 공유 메모리 주소(sec_addr1)에 인젝션할 ‘MZ..’(인포스틸러 PE)를 복사. 여기서 MSBuild.exe의 공유 메모리 주소(sec_addr2)에도 인젝션 PE가 복사.
7. NtWriteVirtualMemory{hProc,MSBuild_PEB+8(2.에서 구한 PEB참조),sec_addr2,0x4}: MSBuilde.exe의 ImageBase를 인젝션 주소로 변경
8. NtResumeThread: 인젝션된 PE를 실행

 

 

3. 프로세스 트리

 

[ 그림  9] RAPIT 행위분석 시스템에 의한 프로세스 생성과정

 

정리하자면 NSIS 악성 샘플을 실행 시 Dll_Loader(varicella.exe)로 DLL을 로드하며, DLL을 통해 로드된 바이너리의 쉘코드가 cmd.exe(or MSBuild.exe)에 인젝션하여 악성 행위가 발현된다.

 

4. 진단

 

해당 패커를 이용한 샘플은 상당수가 Lokibot이나 AgentTesla로 인포스틸러가 대부분이다. 안랩 V3에서는 다음과 같이 악성코드를 탐지하고 있다.

 

• Dropper/Win32.Lokibot (2020.02.07.01)
• Dropper/Win32.NSIS (2020.02.04.04)
• Trojan/Win32.AgentTesla(2020.01.31.06)