★625악성코드의 특징

# DNS 증폭 DDOS(DNS Amplification DDoS, aka SMURF attack)

- 이거 다시 확인

mbr악성코드 특징(0708a979a5c7c3a0450b7ddc37faead7)

네트워크 관련

VICTIM 정보를 XOR 해서 유출(상태 파악)

프로세스 관련

User 계정에 따라 파라미터 -n -b -r -i -p -m -z -d -f -w -t -a 등을 붙혀 실행

defualt

Wow64DisableWow64FsRedirection - 64bit 확인(wow64 리다이렉션 기능을 멈추지만 그 용도로 쓰지는 않는 듯)

WTSEnumerateSessionsW - 계정 정보 검색, 아래 API로 토큰 정보를 수정하여 실행

WTSQueryUserToken

DuplicateTokenEx

SetTokenInformation

-b 옵션

mbr 변조

서비스 관련

Sens, Alerter - 중지

계정 관련

net user [계정] "highanon2013"

del "[계정]\Temp\3F03.tmp.bat"

파일 시스템 관련(PE 파일, 영상 파일, 이미지 파일, 웹 파일, 기타를 확장자로 구분하여 삭제)

GetDriveTypeW

_wmakepath "\\?\E:\*.*"

PathMatchSpecW 확장자 비교 함수 사용

[_remove:00401d40]영상, 이미지 확장자 확인 후 파일 변조, 그 후 다음 루틴

*.nms 파일외 *.exe, *.dll, *.sys, *.ocx은 삭제 또는 SetFileAttributesW 보안 해제 후 삭제

그외 확장자는 처음과 끝을 "20"으로 바꾼뒤 MoveFileW로 랜덤한 파일명으로 변환 & 삭제

# 320때 mbr삭제 악성코드와 연관성은 잘 모르겠다. mbr 악성코드만 보면 비슷하진 않음.

완전히 새로 코드를 짠 느낌.

# 윈도우7 관리자 권한으로 실행시 mbr 변조, 일반권한이면 유저권한의 파일만 삭제

- 윈도우7 기준으로 권한이 있어야 하는데, 그 역할은 아마도 웹하드 업데이터가 해줄 듯

Backdoor.ngrbot

먼저 악성코드가 실행되면 모든 Process를 찾아서 Code Injection을 시도

그림1. 모든 프로세스에 Code Injection

이후 Injection된 Code가 각 Process에서 실행되면 IAT(Import Address Table)를 구성하고 ntdll.LdrEnumerateLoadedModules라는 Native API를 호출한다. LdrEnumerateLoadedModlues는 모든 로드된 모듈을 대상으로 CallBack 함수를 실행하는 API(undocument이지만 실제 그렇게 행동하는 것을 확인함)로 CallBack 함수는 특정 대상 API를 Inline Patch한다. 또한 ‘NtResumeThread’, ‘LdrLoadDll’ 두 함수의 경우 CallBack함수와 별도로 Inline Patch를 한다.

그림2. Inline Patch Code

여기서 ntdll의 Native API 주소는 다음과 같이 PEB_LDR_DATA 정보를 찾아서 로드된 모듈이 ‘ntdll.dll’과 일치할 경우 해당 모듈의 Header 정보를 통해 Export된 Function Offset(address)을 찾는 방법을 사용한다.

그림3. FS레지스터를 통해 로드된 ‘ntdll.dll’를 찾는 과정

그림4. ‘ntdll.dll’의 Header 정보를 통해 특정 API Address를 찾는 과정

분석 시 확인된 Patched API는 다음과 같다. (하지만 악성코드 버전 별로 대상이 상이 함을 확인)

##ntdll - NtQueryDirectoryFile, NtEnumerateValueKey, NtResumeThread, LdrLoadDll

##kernel32 - CopyFileW, CopyFileA, CreateFileW, CreateFileA, MoveFileW, MoveFileA

##wininet - InternetWriteFile, HttpSendRequestW, HttpSendRequestA

##ws2_32 - getaddrinfoW, send

##urlmon - URLDownloadToFileA, URLDownloadToFileW

ngrbot 악성코드는 자기 자신을 %profile%\application data\Random.exe형태의 랜덤 이름으로 복사/레지스트리 등록/실행을 하고 새로운 프로세스에 대해서도 변조를 하기 때문에 안전모드에서 해당 파일을 삭제하면 치료가 가능하다. 따라서 감염된 상태에서 탐지를 위해 User-mode에서의 inline patch를 대응하기 위해 주요 API에 대한 메모리 검사와 같은 조치가 필요할 것이다.

그 외 악성행위 부분은 다음을 참고

http://www.bitdefender.com/VIRUS-1000651-en--Backdoor-IRCBot-Dorkbot-A.html

작년에 분석한건데 공유(&관리) 차원에서 포스팅해 보아요.

1) 드라이버의 설치

최초 웹을 통해 실행되는 Agent 파일에 의해 드라이버가 설치된다.

이후 Agent는 생성한 파일을 서비스에 등록하여 실행시키고 DeviceIoControl 함수를 통해 직접 통신을 한다.

이때 드라이버는 Parameter로 보내지는 Control Code를 기준으로 각각의 명령을 처리한다.

각 Control Code에 대한 분석은 밑에서 다시 자세히 보도록 하자.

2) Driver Entry 분석

먼저 Control Code 명령을 받기 위한 IRP_MJ_DEVICE_CONTROL Object를 생성한다.

이후 IoCreateFile 함수에 대한 SSDT 후킹을 한다. (SSDT Hook같은 경우 이미 많이 보아온 기법이라 자세하게 보지는 않았다.)

후킹이 완료되면 atapi의 DriverObject를 찾아서 DeviceType가 “FILE_DEVICE_DISK”인 DeviceObject를 찾고 Attach된 Device가 "\\Device\\Harddisk0\\DR0"인 경우 그 값을 전역변수로 저장한다.

즉, “\Driver\atapi”를 통해 Attached Device가 “\\Device\\Harddisk0\\DR0”이고 DeviceType이 “FILE_DEVICE_DISK”인 조건의 atapi의 DeviceObject를 찾는 것이다. 이는 Disk에 ReadWrite시 필요한 조건임을 추측 할 수 있다.

3) Read/Write Disk Control Code 분석

위에서 언급했듯 Control Code로 넘어온 값들은 다음과 같이 일정한 조건을 통해 다양한 명령을 수행하게 된다.

Parameter가 222008, 222000인 경우 파일명을 버퍼에 저장하여 로컬에서 접근을 막도록 한다. SSDT와 관련된 내용으로 자세한 분석은 생략한다.

222014의 경우 실제 하드디스크의 특정 Sector에 Write를 수행한다.

넘어오는 Parameter는 Agent에서 보낸 Data로 I/O manager를 통해 SystemBuffer에 포함된다. IRP 데이터의 입출력 처리 방식은 따로 언급하지 않겠다. 다만, SystemBuffer를 사용하는 방식은 IRP_BUFFERED_IO(0X10)이고 IRP + 8 byte offset에 위치한 Flags값으로 확인 가능하다.

위의 그림에서 볼 수 있듯이 SystemBuffer(밑의 80D50DF8)의 + 8 byte offset 위치에 있는 값이 악성코드가 디스크에 쓰는 값이고(밑의 빨간 네모 박스), Sector 번호 및 Sector Counter값이 같이 인자로 넘어온다.

그렇다면 해당 인자를 통해 어떠한 방식으로 물리 디스크에 데이터를 삽입할까?

악성코드가 물리 디스크에 데이터를 Read/Write하는 방식은 다음과 같다.

(1) 임의 메모리에 ScsiRequestBlock(이하 SRB) 구조체를 생성 및 셋팅

(2) ATAPI의 DeviceObject Index를 통해 해당 Device의 비동기적 IRP 생성

(3) 생성한 IRP 셋팅 – Stack에 MajorFunction, SRB 포인터 등을 설정

(4) ATAPI Device에 붙은 Atapi.sys (Driver)의 IRP_MJ_INTERNAL_DEVICE_CONTROL를 호출하여 디스크 접근

다음은 소스코드이다.

위의 코드 중 특별히 확인해야 할 부분은 IRP Stack에 들어가는 MajorFunction이 3(IRP_MJ_READ)인경우 Command Descriptor Block(CDB) 구조체의 OpCode가 Read이고 아닐 경우 Write라는 것이다.

CDB에는 실제 물리 디스크에 어느 위치를 사용할 지 정의할 수 있고 따라서 SRB구조체의 CDB는 디스크 위치를 찾아가는 중요 포인트가 된다.

다음은 MBR Sector를 수정하는 SRB이다.

노란색으로 나타낸 부분이 CDB 부분이며 주황색으로 표시된 부분이 CDB[5]으로 Logical Block Address(LBA)을 나타낸다. LBA는 Sector를 나타내는 번호이고 위의 그림상으로 00 이므로 0번째 Sector가 된다. 0번째 Sector는 Disk의 MBR이 위치하는 곳이다. CDB[7]은 Sector Counter로 몇 개의 Sector를 사용할지 나타낸다. 위의 그림상에서는 01이므로 한 개의 Sector를 사용한다는 뜻이다. (보통의 경우 1개 Sector가 512byte로 만약 쓰고자 하는 데이터가 그 이상이 될 때는 사용할 Sector를 더 많이 지정해 줘야한다.)

CDB는 사용하는 목적에 따라서 여러가지 구조로 정의 할 수 있는데 악성코드에 의해 만들어지는 것은 10 Size 2A(write)로 정의되었다.

CDB(10) Write의 구조

SRB가 셋팅되면 IRP를 생성하고, Stack에 SRB의 구조체를 Parameter로 설정한다.

Stack의 첫번째 0F는 IRP_MJ_INTERNAL_DEVICE_CONTROL(Major Function)을 나타내며 80D7A858은 SRB의 포인터가 된다. IRP_MJ_INTERNAL_DEVICE_CONTROL는 SCSI Request를 요청할 때 SRB 포인터를 Parameter로 설정한다.

이후 IofCallDriver 함수를 통해 atapi driver에게 IRP를 넘기게 되고 Stack에 담겨진 SRB 데이터를 읽어 물리 디스크에 직접 접근하게 된다.

디스크에 Write를 완료하면 Agent는 222020 ControlCode를 호출하게 되는데 이는 atapi driver에 IRP_MJ_INTERNAL_DEVICE_CONTROL함수를 후킹하게 된다.

더 이상 해당 SCSI I/O Request를 수행 할 수 없게 되는 것이다.

디스크에 삽입된 데이터를 분석하면 Anti AV, OnlinegameHack Tool, DownLoader 등이 있으며, 부팅시 변조된 MBR 코드에 의해 자동으로 실행되어 진다.