0. 목차
1. 악성코드 개요
1.1) 개요
호크아이는 최소 2013년부터 지하 암시장에서 거래되던 멀웨어다. 주로 키로깅이나 사용자의 데이터를 훔치는 기능을 하는데 2018년 이후 변종 호크아이 멀웨어가 출현하기 시작하였다. 이는 호크아이 reborn 이라고 불리며 주로 CVE-2017-11882와 같은 오피스 취약점을 이요하여 피싱메일 형태로 주로 배포되고 있다
해당 악성코드에는 난독화가 심하게 되어있어 분석가의 분석을 방해하거나 백신에서도 검사되지 않는다. 또한 코드 인젝션을 통하여 NirSoft 소프트웨어로 사용자의 비밀번호를 탈취하는 주 기능을 포함한다.
1.2) 분석 정보
Default view
Search
Default view
Search
2. 상세분석
2.1) SandBox 분석
Any Run 샌드박스의 분석 결과는 다음과 같다
Any Run Sandbox Process Graph
배포된 악성코드의 이름으로 보아 티켓 예약 메일과 관련한 내용으로 배포된 것으로 유추된다. 해당 악성코드가 실행되면 내부에서 regasm.exe 를 실행시키고 그 하위에 두 개의 vbc.exe 프로그램이 생성 및 실행된다.
어셈블리 등록 도구(RegAsm.exe)
어셈블리 등록 도구를 사용하면 어셈블리 내의 메타데이터를 읽고 필요한 엔트리를 레지스트리에 추가할 수 있다. 이렇게 하면 COM 클라이언트에서 .NET Framework 클래스를 투명하게 만들 수 있다.
C#에서 만든 .DLL 라이브러리를 MFC(C++)에서 사용할려면 .tlb 파일을 생성 및 윈도우즈 레지스트리에 등록하는 과정이 필요하다. 이를 위해서 MS 제공 RegAsm.exe라는 프로그램을 이용해서 처리를 할 수 있다.
RegAsm.exe 프로그램은 MS에서 제공하는 정상적인 프로그램이다. AnyRun 샌드박스에서는 해당 프로그램을 HawkEYE 악성코드로 분류함으로 보아 코드 인젝션으로 악성 행위를 할 것이다. 또한 vbc 프로그램 역시 윈도우에서 제공하는 기본 프로그램으로 인젝션 당하여 수행되는것으로 확인된다
첫 번째 vbc.exe 악성행위
첫번째 Vbc.exe의 분석 정보는 위와 같다.
vbc.exe \stext "C:\Users\admin\AppData\Local\Temp\tmp4399.tmp"
Bash
복사
\stext 라는 옵션으로 tmp 파일을 생성하는데 vbc.exe 는 Nirsoft 사의 프로그램으로 인젝션되어 사용된다.
\stext 옵션은 Nirsoft 프로그램의 수행 결과를 파일로 저장시키는 옵션이다.
두 번째 vbc.exe 악성행위
두 번째 vbc.exe 또한 동일하게 사용자의 중요 정보를 탈취한다
2.2) 행위 분석
Process Moniter로 악성코드(sample.exe)를 실행시킨 로그이다. 샌드박스에서 봤던것처럼 하위에 RegAsm.exe이 생성되었고 그 하위에 2개의 vbc.exe가 실행된걸 볼 수 있다
또한 vbc.exe 프로그램 실행시 인자로 \stext가 주어져 tmpD88.tmp 파일로 결과 값을 저장하는 걸 볼 수 있다.
두번째 vbc.exe 역시 tmpFC00.tmp 파일로 결과 값을 저장한다
tmpD88.tmp, tmpFC00.tmp 둘다 CreateFile, WriteFile, CloseFile의 동작을 확인 할 수 있다
파일 생성 후, QueryNetworkOpenInformationFile Operation을 보면 네트워크 상으로 해당 파일을 전송한다. 그다음 SetDispositionInformation File Operation을 보면 생성한 파일을 삭제한다.
2.3) 정적 분석
해당 악성코드는 Autoit script로 만들어져 pe 형태로 빌드된건 볼 수 있다
void __stdcall sub_403B4C(wchar_t *String)
{
int v1; // ecx
WCHAR *v2; // eax
HWND v3; // eax
const WCHAR *v4; // [esp-10h] [ebp-20044h]
const WCHAR *v5; // [esp-Ch] [ebp-20040h]
WCHAR v6[32768]; // [esp+8h] [ebp-2002Ch] BYREF
WCHAR Buffer[32768]; // [esp+10008h] [ebp-1002Ch] BYREF
LPCWSTR lpFile[4]; // [esp+20008h] [ebp-2Ch] BYREF
LPCWSTR lpParameters; // [esp+20018h] [ebp-1Ch] BYREF
LPWSTR FilePart; // [esp+20028h] [ebp-Ch] BYREF
int v11; // [esp+2002Dh] [ebp-7h] BYREF
sub_4077C7(lpFile);
FilePart = 0;
*(_WORD *)((char *)&v11 + 1) = 0;
GetCurrentDirectoryW(0x7FFFu, Buffer);
sub_403778(String, (int)&v11);
if ( IsDebuggerPresent() )
{
MessageBoxA(0, "This is a third-party compiled AutoIt script.", Caption, 0x10u);
goto LABEL_14;
}
if ( dword_4C62E0 )
{
if ( dword_4C62E0 == 1 )
{
sub_407373((int)&word_4C7290, 1, dword_4C62E8, -1);
byte_4C7292 = byte_4C6284;
goto LABEL_6;
}
if ( sub_4073E5(&word_4C7290, (int)&lpLibFileName, &dword_4C62E0, v1, (int)&v11 + 1) )
{
....
else
{
...
ShellExecuteW(v3, L"runas", v4, v5, Buffer, 1);
sub_405A64((void **)&lpParameters);
}
sub_40743B(&word_4C7290);
goto LABEL_13;
}
dword_4C627C = 1;
}
else
{
dword_4C627C = -1;
}
LABEL_13:
SetCurrentDirectoryW(Buffer);
LABEL_14:
sub_405A64((void **)lpFile);
}
C
복사
안티 디버깅이 적용되어있고, ShellExecuteW()로 스크립트를 동작시키는 것으로 보인다. Autoit script는 exe2aut 를 이용하여 디컴파일 할 수 있다
EXE2AUT 프로그램으로 디컴파일을 하면 9천줄이 넘는 코드가 난독화 되어 나온다. 중요한 부분만 보자면 맨 아래 부분 runpe 라는 함수가 보인다. 변수 명으로 보아 RegAsm.exe 프로세스에 코드 인젝션을 수행하는 것으로 추측 할 수 있다
2.4) 동적 분석
2.4.1) Sample.exe → Code injection
Sample.exe를 x32dbg로 RegAsm.exe에 코드 인젝션하는 부분을 확인해보자.
우선 안티 디버깅 부분을 우회한다
IsDebuggerPresent 함수의 반환값은 디버깅시 1이 나오므로 jmp하게 될 것이다. 따라서 jne ... 어셈을 nop 처리한다.
그다음 CreateProcessW 에 bp를 걸고 진행을 해보면
위와 같이 RegAsm.exe 파일의 path를 인자로 가지고 들어온걸 볼 수 있다. 6번째 인자인 0xc는 해당 프로세스를 일시정지 상태로 만드는 옵션이다.
결국 위 로직은 코드 인젝션을 위해 프로세스의 핸들을 얻어오는 과정이다. 또한 추가적으로 안티 후킹이라는 기법이 적용되어있다.
현재 메모리에 매핑된 dll들의 주소를 보면 7....로 시작한다. 이는 프로그램이 실행 되기 전 초기화 과정에서 미리 로딩된 DLL 들이다. 하지만 로그를 보면
OEP에 진입 후, 추가적으로 dll들을 다시 매핑하는 것을 볼 수 있다. kernel32.dll, ntdll.dll 와 같은 중요 dll 들도 리맵핑한다. 이는 안티 후킹 기법으로 악성코드가 실행시 내부의 dll을 재로드하여 기존 DLL을 사용하는 것이 아닌 재로드한 DLL을 사용하게 된다.
이를 이용하면 샌드박스나 백신의 우회가 가능하다.
CreateProcessW 함수의 호출이 끝나면 RegAsm.exe 프로세스가 일시정지 상태로 실행된다.
이제 안티후킹기법으로 인해 함수에 bp를 그냥 걸게되면 안된다. Ctrl+G 로 함수명을 찾고 거기에 bp를 건다는 의미는 기존 dll api에 bp를 거는 것이고 내부에서 사용하는 API는 재로드된 DLL 이다. 따라서 x32dbg의 tracing command를 이용해야 한다 ⇒ TraceOverBeyondTraceRecord
tobt dis.iscall(cip)==1 // call 어셈을 만날때 stop!
tracing 기능을 이용하여 다음에 실행되는 함수를 보면 zwqueryinformationProcess 인 것을 확인할 수 있다. 정보를 받기 원하는 프로세스의 핸들값이 첫번째 인자로 들어가는데 이는 RegAsm.exe의 핸들이다.
hex(1824) = 0x144
ZwReadVirtualMemory 를 통해 RegAsm.exe의 가상 메모리 영역을 읽어온다
NtCreateSection 함수를 통해 위에서 전에 읽어온 가상 메모리 영역에 공유 섹션을 새로 생성한다
생성한 섹션 핸들(0x14c)를 인자로 하여 메모리 매핑 진행한다. 매핑 할 공유 섹션 주소는 3번째 인자인 0x5fe63c 이고 그 안에 매핑된 주소가 담긴다 (0x5180000)
sample.exe 악성코드에 매핑된 주소가 생성되었다.
2.4.1) RegAsm.exe → Code injection
이번엔 sample.exe의 자식 프로세스로 생선한 RegAsm.exe 프로세스에 매핑을 진행한다. 매핑되는 주소는 ResAsm.exe의 0x400000 섹션이다.
해당 함수의 호출이 끝난 후 RegAsm.exe 프로세스의 0x400000 주소가 매핑된 것을 볼 수 있다. 아직 매핑만 진행한 상태이기 때문에 어떠한 값도 써져있지 않다.
그다음 memcpy로 내부에 들어있던 shellcode(0x2e30020) 를 아까 매핑한 sample.exe의 0x5180000 영역에 0x200 만큼 복사한다. PE 헤더 부분을 먼저 복사하는 것으로 보인다
그다음 0x200 이후의 shellcode 섹션 값들을 복사한다
그 다음 섹션 복사
그 다음 섹션 복사
모든 섹션이 복사되면 코드 인젝션이 마무리 된다. 다시 sample.exe에 인젝션된 메모리를 보면 전과 달리 값이 씌여저 있는 것을 볼 수 있다.
이번엔 Sample.exe의 자식 프로세스인 RegAsm.exe에 코드 인젝션을 진행한다. 이는 매핑된 영역인 0x400000에 써진다.
이제 마지막으로 ZwResumeThread 를 호출하여 일시정지 시킨 RegAsm.exe 프로세스를 깨운다. 첫번째 인자를 보면 0x148 핸들값을 볼 수 있는데 이는 RegAsm.exe의 핸들값이다. (중간에 껏다가 켜서 PID값이 달라졌다. )
따라서 RegAsm.exe에 인젝션된 쉘코드를 추출해보자
2.4.3) shellcode 추출
추출한 쉘코드이다. 현재 IAT가 깨져있어 복수를 해줘야한다. PE-bear 툴을 이용하여 Viratul Address를 맞춰주면 복구가 된다
복구가 되었다. 이제 새로 저장을 한 뒤 해당 쉘코드를 분석해보자
2.4.4) shellcode 분석
Confuser 라는 protector로 패킹되어있다.
dnspy로 디컴파일을 진행하면 굉장히 난독화가 심하게 되어있다. 따라서 dot2net 툴을 이용하여 난독화 해제를 진행해야한다
> de4dot.exe -f "추출한 shellcode" -f "생성할 파일이름"
Bash
복사
난독화가 완벽히는 아니지만 어느정도 복호화가 되었다. 변수명과 클래스 이름들이 rename 되어있다. 처음으로 호출되는 smethod_0()을 봐보자
26라인을 보면 RCDATA 영역에 들어있는 데이터를 byte배열로 저장한다. 그다음 56라인에서 smethod_12함수를 통해 수행된 결과를 byte_2 배열에 저장한다. smethod_12 함수를 보면
ICryptoTransform 인터페이스를 이용하여 첫번째 인자로 들어온 값을 복호화를 진행한다.
smethod_9 를 보면 RijndaeLManaged 알고리즘을 이용한다는 것을 알 수 있다. 따라서 Main함수의 Case 6 에서 byte_2 배열에 담기는 값은 Resource 영역에 저장된 데이터가 복호화 되서 담긴다고 추측할 수 있다. 어떠한 값이 담기는지 확인해보자
byte_2 배열 저장
저장된 데이터를 확인해 보면 악성코드에 대한 정보들을 확인 할 수 있다
•
HawkEye Keylogger
•
Version
•
Reborn v9
•
FTP server, proxy 등
•
webcam keylogger, systeminfo, screenshotlogger, clipboardlogger, keystrokelogger 등
•
billibilli11@yandex.com
•
smtp.yandex.com
◦
탈취한 정보를 전송하는 주소로 확인됨
GEnum0,1 열거채를 통해서 탈취하는 목록을 확인 할 수 있다.
GClass33에는 주요 API들이 들어있다. 해다 함수들을 이용하여 키로거가 시행된다
GClass35에는 주요 변수들이 저장되어 있다. 변수명으로 보아 전에 추출했던 정보들과 일치한다. 안티 디버깅 기능, 안티 바이러스 kill, bot kill 등의 기능과 키로깅 등의 작업이 예상된다
완벽한 언팩이 진행되지 않아서 그런지 디버깅이 중간에 자꾸 꺼져버린다. 중요 함수들을 확인해봤으니 x32dbg로 예외처리를 추가한뒤 진행해보자.
우선 RegAsm.exe에 인젝션 당한 쉘코드를 아까 추출했다. 샌드박스에서 본 것처럼 자식 프로세스로 vcb.exe를 생성한다.
2.4.5) vbc.exe → Code Injection
첫번째 인자로 vbc.exe가 들어가고 두번째 인자로 수행시킬 커맨드라인이 들어간다. tmp0E26.tmp 파일 이름으로 어떠한 정보가 들어갈 거시다. 또한 6번째 인자를 통해 vbc.exe 역시 일시정지 상태로 생성된다
하위에 vbc.exe가 생성됬다.
이제 vbc.exe 역시 이전과 동일하게 공유 메모리 섹션을 생성하고 메모리 매핑을 통해 정상 vbc.exe에 코드 인젝션을 수행할 것이다. 바로 NtWriteVirtualMemory에 bp를 걸고 확인을 해보자
vbc.exe의 0x400000에 매핑된 주소를 확인할 수 있고, 그 곳에 인젝션을 수행한다. 마지막으로 NtResumeThread 에 bp를 걸어 확인해보자
vbc.exe에 코드 인젝션이 되었다. 해당 메모리를 덤프를 떠서 어떠한 프로그램인지 확인해보자.
추출한 덤프도 IAT 복구를 위해 PE-bear로 작업을 해야한다
IAT 복구 후 실행시켜보면 WebBrowerPassView 프로그램이 실행된다.
이는 NirSoft 사의 소프트웨어로 브라우저에 저장된 자동 로그인 계정을 복구해준다. vbc.exe에 인젝션되어 해당 프로그램이 수행되는것이다. 결국 생성했던 tmp 파일에 탈취한 정보를 저장한 뒤 서버로 전송하게 된다
이번엔 두번째 vbc.exe를 확인해보자
이번엔 tmp84A4.tmp 이름으로 탈취한 정보를 저장한다. 바로 NtResumeThread 에 bp를 걸고 인젝션 당한 데이터를 확인해보자
두번째로는 Nirsoft사의 Mail PassView 프로그램이다. 이는 메일 계정을 복구해주는 소프트웨어이다.
•
Outlook Express
•
Microsoft Outlook 2000 (POP3 and SMTP Accounts only)
•
Microsoft Outlook 2002/2003/2007/2010/2013/2016 (POP3, IMAP, HTTP and SMTP Accounts)
•
Windows Mail
•
Windows Live Mail
•
IncrediMail
•
Eudora
등등의 메일들의 계정을 복구해준다. 결국 두번째로는 사용자의 메일 계정을 탈취한다는 것을 알 수 있다.
3. 정리
호크아이 악성코드의 전체 프로세스는 다음과 같다
1.
Autoit script로 생성 ⇒ PE
2.
createprocess ⇒ RegAsm.exe
3.
Code Injection
a.
In Self Process
b.
In RegAsm.exe
4.
Code Injection
a.
In vbc.exe ⇒ WebBrowerPassView
b.
In vbc.exe ⇒ Mail PassView
c.
execute vbc.exe ⇒ save In .tmp file
5.
Send tmp file to C2
6.
Delete tmp file
confuserex protector에 의해서 난독화된 쉘코드를 전부 언팩하지 못했다. 그로인해 추후 dnspy로 디버깅이 불가하여 주요 부분만 확인하였고 x32dbg로 행위기반 분석을 통해 확인한 로직을 기반으로 api로 동적 분석을 진행하였다.
완벽하게 분석하지 못했지만 추후 .net 기반으로 작성된 악성코드의 분석 실력을 더 높인후 다시 진행해볼 예정이다.
