첫번째 _bot.exe프로세스가 CreateProcess로 자기자신을 자식프로세스로 생성하게 되는데요 그 생성된 프로세스를 분석해 보겠습니다.

우선 이번에도 분석하기전에 분석대상 실행파일에서 대략 코드의 흐름을 보겠습니다.

 

[그림.1]

 

이번에도 툴을 돌려서 확인하겠습니다.ㅋ

이번 분석대상은 CreateProcess로 호출된 _bot.exe의 자식프로세스 입니다. 

 

[그림.2]

분석이 완료되고 Report결과를 보면 함수가 별로 호출이 안되네요.

윗부분 몇줄은 _bot.exe의 부모프로세스와 동일하고 메모리주소 0x1511267F lstrcpy부터 코드가 틀린것을 확인 할 수 있습니다.

지금부터 코드는 _bot.exe가 아닌 _bot.exe의 자식프로세스의 이름을 _bot_petch.exe라고 하겠습니다.

_bot_petch.exe라고 지은 이유는 자식프로세스로 생성되는 녀석에 EP에 INT 3(0xCC)로 소프트웨어 브레이크 포인트를 설정하여 코드 패치를 하고 분석을 진행 했기 때문입니다.

 

 [그림.3]

 

 

이 자식 프로세스에서의 흐름은 부모 프로세스가 뮤텍스를 갖고 있기 때문에 GetLastError에서 리턴으로 0x0B7을 리턴합니다.

이 값의 의미는 위에서 설명을 했기 때문에 생략하겠습니다.

CMP EAX(0x0B7),0B7은 JNZ분기문의 조건에 맞지 않으므로 점프하지 않고 아래의 함수 0x15112650을 호출하게 됩니다.

그럼 함수 내부로 진입하여 분석을 이어가겠습니다.

 

[그림.4]

함수내부로 들어가면 위의그림과 같습니다.

svchost.exe의 경로를 만들고 그 경로에있는 svchost.exe를 자식프로세스로 생성을합니다.

벌써 두번째 자식프로세스 생성입니다.(자식좀 그만 낳았으면 좋겠지만 어떤 녀석들인지 알아야겠지요-0-)

여기서 중요한점은 생성할때 CreationFlags를 CREATE_SUSPENED로 호출한다는 점입니다.

이렇게 호출 될 경우 프로세스가 생성될때 정지 상태로 생성하게 됩니다.(느낌에 svchost.exe가 수술당할 것 같은 느낌이 드네요.. -0-)

 

 

 [그림.5]

 

그리고 _bot_petch.exe의 힙 영역에 자기자신의 코드를 복사하기 위해 VirtualAlloc함수를 호출하여 코드사이즈만큼 메모리 공간을 만듭니다.

호출이후 리턴된 메모리주소는 0x00B70000입니다.

그리고 GetCurrentProcess함수로 현재 실행중인 _bot_petch.exe의 HANDLE을 구하고 할당된 힙 영역에 자기자신의 코드를 그대로 복사합니다.

 

 [그림.6]

 

현재 생성된 프로세스를 확인하겠습니다.

첫번째 부모프로세스 _bot_fetch.exe(_bot.exe) 와 첫번째 자식 프로세스인 _bot_petch.exe 그리고 이 녀석이 낳은 또하나의 자식 프로세스인 svchost.exe가 메모리에 올라와있습니다.

이중에서 svchost.exe에 무언가 작업(수술-0-)을 하기위해 Suspended로 호출된 상태이구요.

 

[그림.7]

본격적으로 svchost.exe에 작업을 하는 코드입니다.

우선 _bot_petch.exe 의 힙 영역에 자기자신의 코드를 저장한 상태에서 VirtualAllocEx 함수로 svchost.exe의 HANDLE 0x88 과 _bot_petch.exe 의 Sizeofimage 0xA0000(코드크기) svchost.exe에 생성할 힙 주소를 0x15110000으로 세팅하고 PAGE_EXECUETE_READWRITE의 메모리 권한으로 생성합니다.

결국 이렇게 되면 svchost.exe에 0x15110000 주소의 힙 영역이 생성이 되고, 그 생성된 사이즈는 0xA0000이 됩니다.

하지만 아직까진 svchost.exe에 생성된 힙 영역은 빈공간 입니다.

이것을 아래 그림을 통해 확인해 보겠습니다.

 

[그림.8]

 

메모리 영역의 확인은 sysinternals에서 제공하는 VMMap.exe 툴을 사용하여 확인이 가능합니다.

왼쪽이 VirtualAllocEx 함수를 호출 하기 전 이고 오른쪽이 함수 호출 후 입니다.

오른쪽을 보면 0x15110000 svchost.exe 프로세스의 힙 메모리 영역에 0x15110000이 생성된 것을 확인 할 수 있습니다.

 

[그림.9]

 

그리고 svchost.exe의 힙 영역에 생성된 코드 부분으로 코드의 실행 제어권을 넘기게되는데 이부분을 보기전에 잠시 확인하고 가야될 부분이 있습니다.

그림.4에서 CreateProcess 함수로 실행됬던 svchost.exe파일의 pProcessInfo에 LPPROCESS_INFORMATION 구조체가 들어 가게 됩니다.

그부분을 확인해보면 svchost.exe정보를 확인 할 수 있는데 그 정보들은 그림.9와 같고 Thread Handle이 0x98인것으로 확인이 가능합니다.

 

[그림.10]

 

여기서 svchost.exe의 EIP를 변경함으로써 코드의 흐름을 변경하게 되는데요.

우선 CONTEXT 구조체를 세팅하고 GetThreadContext로 svchost.exe의 CONTEXT를 가져옵니다.

이 구조체안에는 EDI,ESI,EBX,EDX,ECX,EAX,EIP,EBP,ESP와 EPLAGS 또는 CONTEXTFLAGS 등의 정보들로 채워지고 레지스터에 세팅되는 값들은 현재 EIP에 해당하는 값들로 세팅이 됩니다.

그림.10에서 왼쪽 그림에 GetThreadContext 호출했을때 HEX창을 확인 했을때 보여지는 값이 svchost.exe의 현제 EIP레지스터 값이며 0x7C7E0735로 세팅되어 있습니다.

그리고 오른쪽 그림의 코드상 메모리주소 0x15112700에 보면 다음과 같은 코드가 있습니다.

MOV DWORD PTR SS:[EBP-378],EDX

이 콛드는 CONTEXT.EIP = 0x151130F0로 해석할 수 있으며, 이 의미는 svchost.exe의 EIP주소를 0x151130F0 세팅하겠다는 의미입니다.

즉 svchost.exe의 힙 영역에 붙여넣은 코드 0x15110000에서 정확히 .text section 코드섹션의 시작지점으로 EIP를 변경하여 실행하게 되는 것입니다.

이제 마지막으로 SetThreadContext 함수로 svchost.exe 프로세스의 CONTEXT 정보를 수정한 CONTEXT로 세팅하게 되고, 마지막으로 ResumeThread 함수로 suspended된 svchost.exe프로세스를 실행하게됩니다.

 

 

[그림.11]

 

이번에도 스레드에 IN3 소프트웨어 브레이크 포인터를 걸어서 실행했더니 JIT(just...?)실행이 안되더라구요..(Attach List 목록에 svchost가 없습니다. ㅠ)

그래서 스레드의 코드실행 첫라인 2바이트에 현재 라인으로 점프하는 코드 EBFE 를 걸어 현재의 명령어 라인에 무한루프롤 돌게끔 걸어놓고 분석을 진행했습니다.

그랬더니 CPU 사용량이 막올라가네요.

이상태에서 Attach List 목록을 확인해 보면 svchost.exe가 올라와 있는것을 볼 수 있습니다.

 

[그림.12]

svchost.exe와 attach 해서 코드 내로 진입했습니다.

대충 보면 소켓함수와 wininet.dll 라이브러리를 쓰네요 인터넷연결과 소켓통신을 하려고 하는 모양인데 자세한건 분석해 봐야겠지만 재미있을것 같네요..ㅎㅎ;

이것으로 두번째 프로세스 분석을 마치겠습니다~

 

posted by 미스터리 DKL