CreateMutex
까보면 다나와~
악성코드 상세분석 (9)

625 mbr악성코드 간이 분석.. (625 mbr malware simple analysis)


★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 기준으로 권한이 있어야 하는데, 그 역할은 아마도 웹하드 업데이터가 해줄 듯


  Comments,   0  Trackbacks
댓글 쓰기

Backdoor.ngrbot

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

 

여기서 ntdllNative 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

'악성코드 상세분석 > BOT' 카테고리의 다른 글

Backdoor.ngrbot  (0) 2012.12.26
Koobface 악성코드 분석  (0) 2010.10.18
  Comments,   0  Trackbacks
댓글 쓰기

Bootkit 심층분석

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




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를 찾아서 DeviceTypeFILE_DEVICE_DISK” DeviceObject를 찾고 Attach Device"\\Device\\Harddisk0\\DR0"인 경우 그 값을 전역변수로 저장한다.

 

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

 

3) Read/Write Disk Control Code 분석

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

  

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

 

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


 

넘어오는 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 셋팅 – StackMajorFunction, 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의 첫번째 0FIRP_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 driverIRP_MJ_INTERNAL_DEVICE_CONTROL함수를 후킹하게 된다.

  

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

  


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

  Comments,   0  Trackbacks
댓글 쓰기

ahnurl.sys 루트킷 드라이버 분석

1. 드럽퍼에 의한 실행 흐름

 


2. 상세 분석

1) DKOM을 이용한 드라이버 은닉

 

다음은 설치된 ahnurl 드라이버에 대한 오브젝트 일부이다. 드라이버는 스스로를 은닉하기 위해 오브젝트 오프셋 +14h 위치의 (DriverSection) 메모리를 접근한다. DriverSection은 이중 링크드 리스트로 이루어진 드라이버 리스트에 대한 정보를 제공하기 때문에 여기에 접근하여 링크된 리스트 항목의 앞 뒤 드라이버를 자신을 뺀 채 연결하고 자신을 리스트에서 조회되지 않도록 수정한다.

 

2) SSDT Hook

 

악성코드는 자신을 보호하기 위해 다음의 Native API대해 Hook을 한다.

NtQueryDirectoryFile(+244), NtEnumerateKey(+11c), ZwEnumerateValueKey(+124)

 위의 함수들은 레지스트리 및 파일을 조회할 때 호출되는데, 이는 인자값을 감시하여 자신이 원하는 레지스트리나 파일을 삭제하지 못 하도록 보호하기 위함이다. *Hook으로 인해 실행되는 함수는 별도로 분석하지 않았다.

 

3) NtMapViewOfSection API Inline Code Patch

 

우선 NtMapViewOfSection함수를 패치하는 목적은 다음과 같다.

프로세스는 새롭게 생성될 때 OS에 의해 독립적인 유저 메모리를 공간을 할당받고 이 공간을 통해서 코드를 실행한다. 특히 DLL은 효율적인 메모리 활용을 위해 Mapping된 파일을 불러오게 되어 있는데 해당 정보를 조회할 때 NtMapViewOfsection이 호출되게 된다. 따라서 이 함수를 수정하면 DLL이 로드됨과 동시에 자신이 원하는 행동도 임의 실행할 수 있게 되는 것이다.

Patch가 된 NtMapViewOfSection API는 사전에 buffer에 저장한 주소로 점프하게 되는데 해당 주소코드의 역할은 주요 온라인게임 계정을 해킹하는 악성코드 DLL파일을 로드하게 된다.

 

  Comments,   0  Trackbacks
댓글 쓰기

온라인 게임 드롭퍼
01.exe(3BDC8A7D5A8DDD71E58A5E85AFE43C27) 2011/01/xx

주요 핵심 루틴
1. exception
2. Anti - AntiVirus(AYAgent.aye SkyMon.exe),
 (CreateToolhelp32Snapshot -> Process32First -> _stricmp -> OpenProcess -> TerminateProcess) 프로세스 종료 루틴
3. WFP unlock - sfc_os.dll #5
4. MoveFileExA ComRes.dll -> ComResA.dll
5. CreateFile(FindResourceA) -> ComRes.dll
6. delete itself (wsprintfA -> WinExec)

ps. dummy API - lstrcmpA
  Comments,   0  Trackbacks
댓글 쓰기

spoo1sv.exe 분석내용(이미지 포함)
처리님 블로그거 불펌????!!! ㅋㅋ

--------------------------------------------------------------------

최근 정상파일을 변경하여 악의적인 목적으로 사용되는 경우가 매우 많이 일어나고 있기 때문에 이번 내용은 이슈는 아니다.
하지만, 이 포스팅을 쓰는 이유는 기존에 나왔던 파일과는 다른 파일명을 사용하여서 기록용으로 포스팅을 한다.

ws2help.dll은 기본적인 Windows에 들어가 있는 정상파일로써, 최근 악성코드에 의해 변조되어 악의적인 행위로 사용되고 있다.
<정상파일 정보>
파일명 : ws2help.dll(Windows Socket 2.0 Helper for Windows NT)
파일위치 : C:\Windows\system32
 


1DB51F51F0602A8FA74AB4FD3E6A872B,19968(XP SP2) - 5.1.2600.2180
90AFFACB3C4F110BA63DF2BE93F2E41A,19968(XP SP3) - 5.1.2600.5512
808AABDF9337312195CAFF76D1804786, 4608(Win7 SP1) -  6.1.7600.16385


이번 악성코드의 특징은 악성 ws2help.dll 과 드롭퍼 자체를 DAT 파일로 백업하여 생성 해 둔 파일이 삭제 시 원상복구 시킨다.
전체적인 흐름은 아래 그림과 같다!!



- 생성 되는 악성 파일
C:\Windows\spoo1sv.exe 
C:\WINDOWS\system32\ws2help.dll
C:\WINDOWS\system32\wimedump.dll 
C:\Windows\tasks\SA01.dat

C:\Windows\tasks\SA02.dat



그럼 간단하게 분석을 해보자~!!

우선 드롭퍼는 자신이 해당 PC에서 자신의 파일이 실행되었는지 Windows폴더에 winurl.dat 확인한다.


이후 감염PC에 생성 할 ws2help.dll의 백업파일을 C:\WINDOWS\tasks\SA01.dat로 생성한다.
여기서 재미있는것은 헤더 시그니쳐를 0x30, 0x30 으로 수정한다는 점이다.(보안제품의 탐지를 우회하려는 행위 인듯...)





악성 ws2help.dll의 백업이 끝나면 현재 실행중인 드롭퍼 또한 C:\WINDOWS\tasks\SA02.dat 파일로 백업시킨다.
그리고 C:\WINDOWS\Windows폴더에 spoo1sv.exe 로 복사한다.




자신의 복사 및 백업파일 저장 작업이 끝나면 ws2help.dll 파일에 대한 WFP(Windows File Protection)를 해제한다.
그리고 %system32%폴더에 wimedump.dll 파일이 있는지 확인 후, 없다면 정상 ws2help.dll 파일을 wimedump.dll 파일이름으로
변경한다.  




그리고 system32폴더와 system32\dllcache 폴더에 리소스로 가지고 있던 악성 ws2help.dll 파일을 생성한다.



이번 악성 ws2help.dll의 경우는 원본파일의 코드를 가지고 있지 않아서 백업 한 wimedump.dll 파일의 Export Table을 참조한다.





모든 작업을 마친 드롭퍼는 자신을 삭제하고 ws2help.dll에 의해 windows폴더내의 spoo1sv.exe 행태로 다시 실행된다. spoo1sv.exe로 실행되면 처음과 다른 아래와 같은 루트를 따라간다.

삭제시키는 국내 보안프로그램은 아래그림과 같이 V3 365, V3 Lite, Naver 백신, Alyac 총 4가지이며 알약은 1.0만 해당된다.(2.0은 안전) 



현재 알약에서는 Spyware.OnlineGames.wime, Trojan.Drpper.OnlineGames.wime으로 탐지한다.



  Comments,   0  Trackbacks
댓글 쓰기

spoo1sv.exe

spoo1sv.exe (게임 계정 해킹 프로그램 드럽퍼)

-> IAT reconstruction
-> Create "C:\\WINDOWS\\tasks\\SA01.dat" (Resource of Malicious Dll) -> MZ => 3030
-> Copy itself "C:\\WINDOWS\\tasks\\SA02.dat"
-> Copy itself "C:\\WINDOWS\\spoo1sv.exe"
-> Change signature "C:\\WINDOWS\\tasks\\SA02.dat" MZ to 00
-> sfc_os.dll load and WPA clear ("C:\\WINDOWS\\system32\\ws2help.dll", "C:\\WINDOWS\\system32\\dllcache\\ws2help.dll")
-> check "%system32%\wimedump.dll" file exists. if the file does not exists, move file from wehelp.dll to wimedump.dll(same directory)
-> Create "C:\\WINDOWS\\system32\\ws2help.dll" (Resource of Malicious Dll)
-> Copy "C:\\WINDOWS\\system32\\ws2help.dll" to "C:\\WINDOWS\\system32\\dllcache\\ws2help.dll"
-> Create_Version_File
-> Delete itself

추가 - (우와 이거때문에 많은 분이 찾으셨네요.)

치료하려면
0. 우선 프로세스 목록에서 spoo1sv.exe를 종료하고 spoo1sv.exe를 삭제
1. "C:\windows\system32\dllcache\ws2help.dll" -> 삭제
2. "C:\windows\system32\ws2help.dll" -> 삭제
3. "C:\windows\system32\wimedump.dll.dll" -> ws2help.dll로 이름 변경 ->
"C:\windows\system32\dllcache\"에 복사
4. windows 폴더에서 winurl.dat, version.dat 삭제

또는 알약2.0 버젼으로 설치하셔서 치료(2.0대 버젼에서 안티백신 로직을 잘 피해갔네요.)

  Comments,   0  Trackbacks
댓글 쓰기

3.3 DDOS

 
간만에 포스팅을 해본다. 3월 3일 최초 발견되어 이슈가 되었던 DDOS 악성코드를 분석해보았다.

흐름도


악성코드가 동작하는 큰 흐름은 위의 그림과 같다. 공격시간을 체크하고 도메인을 확인한 후 해당 도메인으로 공격시간에 맞추어 DDOS를 감행하는 로직이다. 7.7 DDOS와 대동소이하다고 할 수 있겠다.

특징위주로 분석을 해보자면 다음과 같다. 참고용으로 봐주면 좋겠다.



1) tlntwye.dat 파일의 로드

그림 1. tlntwye.dat의 바이너리


앞서 언급한 바와 같이 tlntwye.dat 파일은 특정 시간(이하 공격시간)이 바이너리 형태로 저장되어 있다. 이는 FPU 레지스터(실수 표현을 위해 사용되는 레지스터)에 사용되는 값으로, GetSystemTime API로 얻어진 현재 시간(국제표준시)을 SystemTimeToVariantTime API의 인자로 넣어 얻어진 값과 비교된다.

그림 2. 공격시간(tlntwye.dat의 바이너리)과 현재시간의 비교


현재시간의 년도를 2011로 고정하고 공격시간 보다 작으면 대기, 크거나 같으면 tlntwye.dat 파일을 삭제 한다. 공격시간이 담긴 파일은 이후 사용되지 않기 때문에 삭제하여 추적을 회피하려 했음을 알 수 있다.

그림 3. 공격시간까지 1분 단위 재비교


 



2) tljoqgv.dat 파일의 로드

공격시간이 되면 도메인 정보를 포함한 tljoqgv.dat 파일을 메모리에 로드한다. 하지만 내부 스트링을 확인하면 난독화가 되어 있어 내용을 확인 할 수 없고 일정 루틴을 따라 복호화를 진행 해야만 한다.

그림 4. dat 파일 복호화 전/후


실제 복호화가 시작되는 부분은 dat + 8 offset 부터이고 16byte씩 size 만큼 복호화 하도록 되어 있다.

그림 5. 16byte 씩 size만큼 복호화

 



3) IP 주소 및 개수 저장

dat가 복호화되면 도메인 list 정보를 바탕으로 DNS Query를 날려 IP 주소 및 필요한 정보를 메모리에 저장한다.

그림 6. IP 정보 저장 코드


위의 그림은 복호화된 메모리 영역에 미리 저장된 Offset 마다 필요한 정보를 저장하는 부분을 나타낸 것이다.
gethostbyname 함수를 이용하여 얻어짂 IP 개수와 값들을 저장한다.

그림 7. 일정 Offset에 IP 정보 저장


도메인이 있는 메모리 주소 + 161 offset에 반환된 IP 값들을 저장
도메인이 있는 메모리 주소 + 289 offset에 반환된 IP들의 총 개수를 저장

최초 도메인이 있는 메모리 주소의 + 302 offset 부분에 다음 도메인이 고정적으로 존재하고 그사이 특정 Offset에 공격에 필요한 정보를 저장한다.




4) 공격 Thread 생성

대부분의 DDOS 악성코드가 그렇듯 이번 악성코드도 다수의 스레드를 생성하여 대량의 패킷을 발송하도록 제작되었다. 생성되는 구조를 살펴보면 아래 그림과 같이 특정 조건대로 만들어 진다.

그림 8. Thread 생성 로직


* 도메인 확인 -> 지정된 값만큼 스레드 생성 -> 다음 도메인 확인 -> 지정된 값만큼 스레드 생성 -> (반복)

코드대로 풀어서 설명하자면, 최초 도메인이 있는 주소를 확인하고 + 298 offset 만큼 떨어짂 지점의 값을 확인한다. 해당 값은 스레드를 생성하는 값이 저장되어 있으며, 그 만큼 CreateThread 함수를 호출한다. 해당 값만큼 CreateThread를 완료하면 다음 + 302 offset 주소(다음 도메인이 있는 주소)를 따라 다시 + 298 offset 만큼 떨어짂 지점의 값 확인 후 CreateThread를 반복하게 된다.

모든 도메인에 대하여 스레드 생성을 완료하면 Sleep 함수로 5분 만큼 대기 후 다시 도메인 파일(tljoqgv.dat)을 읽어오는 루틴으로 돌아갂다. 이는 도메인 파일이 변경될 수 있음을 알 수 있다.

다음은 바이너리에서의 값이 표시된 모습과 도메인 별 지정된 값을 정리한 것이다.

그림 9. +298 offset에 지정된 값


 * 지정된 스레드 개수(화살표는 2차, 없는 것은 도메인 삭제)




5) 공격 Thread 패킷 발송

스레드가 한 개의 IP에 발송하는 패킷은 UDP*1, ICMP*1, HTTP*5로 총 7개이다. IP가 20개 이면 20*7이다.

그림 10. Thread가 발송하는 패킷


생성되는 로직을 좀 더 자세히 살펴 보면 다음과 같다.

그림 11. UDP, ICMP 패킷 발송 코드


+289 offset에 저장된 IP 개수를 확인하여 해당 IP 별로 순차적으로 UDP, ICMP, HTTP 패킷을 보내도록 되어있다.
UDP와 ICMP 패킷 발송 젂에 +296, +297 값을 확인하는데, 각각의 값은 실행여부를 확인하는 플레그 값이고
모든 같은 offset의 위치에서 01로 셋팅되어, 결과적으로 항상 작동 되도록 되어 있다.

* 참고로 UDP, ICMP, HTTP 프로토콜을 만드는 API는 socket()으로, 해당 API의 파라미터 값에 따라 설정된다.

그림 12. HTTP 공격과 반복


HTTP 패킷은 좀 더 복잡한 구조로 만들어진다. 공격자는 다음과 같이 미리 스트링을 준비하고 %s로 인자를 받아서 공격 패킷을 조합한다.

GET %s HTTP/1.1..
Accept: %s..
Accept-Language: ko..
User-Agent: %s..
Accept-Encoding: gzip, deflate..%s
Proxy-Connection: Keep-Alive..
Host: ww*.%s.....*/*.
Cache-Control: no-store, must-revalidate.


첫 번째 %s는 고정적으로 “/”이다.
두 번째와 세 번째 %s는 아래 그림과 같이 몇 가지 case를 만들어 랜덤하게 들어갂다.
네 번째는 값이 없고, 다섯 번째는 도메인 스트링이다.

다음은 랜덤하게 들어가는 두 번째와 세 번째 값들에 대해 알아본 것이다.

그림 13. “User-Agent”와 “Accept”를 구성하는 로직


각각의 case string을 확인해 보면 다음과 같다.

 

User-Agent string

Mozilla/5.0 (X11; U; Linux i686; ko-KR; rv:1.9.0.4) Gecko/2008111217 Fedora/3.0.4-1.fc10 Firefox/3.0.4.

Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8.

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1).

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0).

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0).

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2).

 

Accept string

*/*.

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.

image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*.

image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, */*.

image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*.

 

그림 14. 조합된 패킷



6) Thread 종료

7.7 DDOS의 경우 종료 시간까지 명시되어 있지만 이번 3.3 DDOS의 경우 종료를 하지 않고 앞서 확인한 바와 같이 5분 마다 지정된 만큼 스레드를 만들어 공격을 더욱 가중시킨다.

종합해서 정리하면,

① 도메인 dat 파일 확인
② 스레드를 도메인 별로 지정된 만큼 생성
③ 도메인으로 IP 검색
④ IP별로 UDP, ICMP, HTTP(Get flood & CC Attack) 패킷 발송
⑤ 5분 마다 다시 도메인 dat 파일 확인
⑥ DDOS 스레드 생성 및 공격

이후 다른 파일에 의한 disk 파괴

'악성코드 상세분석 > DDOS' 카테고리의 다른 글

3.3 DDOS  (0) 2011.03.22
  Comments,   0  Trackbacks
댓글 쓰기

Koobface 악성코드 분석

파일명

setup02220.exe 또는ld32.exe (숫자는 버전을 뜻함)

탐지명

V.TRJ.Koobface.gen

주요 행동

C&C 서버의 명령에 따라 다른 악성코드를 다운로드하여 실행시킨다.

 

실행 순서는 다음과 같다.


파일 전반적으로 리버싱을 방해하는 요소가 많이 있는데 대표적인 것이 Garbage Code이다.

Garbage

+



위에 그림 가운데 있는 게 Garbage code이고 실제 사용되어질 문자열은 중간중간에 나뉘어져 있다. 이것을 다시 메모리에서 조합하여 사용한다.


정해진 규칙에 따라 Command stream을 해석하여 victim PC에서 수행한다.


분석시 확인 핛 수 있었던 명령은 총 6개로, V32에서 적용되는 것으로 보이며 아래와 같은 역할을 한다.
① WAIT : 60000ms(1분) 갂 대기
② BASEDOMAIN : 명령 수행을 목표로핚 도메인을 추가(추정)
③ UPDATE : 새로운 버젂의 setup파일(“%temp%\okoup_%d.exe”)을 다운로드하고 실행
④ STARTONCE : 특정(주로 SNS를 목표로핚) 파일(“%temp%\zpskon_%d.exe”)을 다운로드하고 실행
⑤ FFSTART : %Program Files%\Mozilla Firefox\ftemp.exe(악성)을 다운로드하고 실행
⑥ START : 특정 파일(“%temp%\rar_%d.exe”)을 다운로드하고 실행

'악성코드 상세분석 > BOT' 카테고리의 다른 글

Backdoor.ngrbot  (0) 2012.12.26
Koobface 악성코드 분석  (0) 2010.10.18
  Comments,   0  Trackbacks
댓글 쓰기