KISA를 보면

악성코드 경유지 사이트, 악성코드 유포지 사이트를 추적하는 시스템을 기술을 설명한다.

근데 악성코드 경유지, 악성코드 유포지 사이트라고 하니 자꾸 혼동된다.

악성코드 경유지는 변조된 사이트, 즉 서비스 중인 웹사이트이고 악성코드 유포지는 실제 악성코드가 담겨있는 곳..

개인적으로.. 모사이트를 통해 악성코드가 유포되고 있으면 모사이트가 유포지 아닌가 싶다.

악성코드는 그 사이트를 통해 유포되고 있는데...

내부가 어떤 구조를 이루고 있든 사용자 입장에서 

모사이트 접속 = 악성코드 설치, 모 사이트는 악성코드 유포지라고 해야 할 거 같다.

또한 그 모사이트는 유포지로서 책임을 져야한다.

그냥..

http://www.securelist.com/en/blog/208194070/Java_0day_Mass_Exploit_Distribution

http://www.symantec.com/connect/blogs/java-zero-day-dished-cool-exploit-kit

CVE-2013-0422

새해 선물 JAVA 0-day 

Java 0day Mass Exploit Distribution

자가보호를 해제하기 위해 API 후킹을 해제하는 악성코드 

"MOV EDI EDI"

악성코드 입장에서는 후킹만 해제하면 되니 참 속편한 듯

후킹해제는 보안 프로그램에서 사용 할 수도 있으니 악성코드라고 보기도 힘든거 같다.

끝없는 창과 방패의 싸움

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

irp->IoStatus.Status = 0; 

실패;

Status의 값은 IRP 요청이 성공했는지 여부를 알려주는 값을 넘겨줌.

0이 아니면 성공, 0이면 실패

http://www.codeguru.com/cpp/misc/misc/system/article.php/c8973/Determine-Windows-Version-and-Edition.htm

-----

The first difference is made by the major version:

• 3 is for Windows NT 3.5
• 4 is for the Windows NT 4
• 5 is for Windows 2000, Windows XP, Windows Server 2003 and Windows Home Server
• 6 is for Windows Vista, Windows Server 2008 and Windows 7

SystemInformationClass Hex값까지 추가해서 올립니다. 

먼저 NtQuerySystemInformation은 첫번째 인자인 SystemInformationClass를 참조하여 어떤 정보를 보여줄 것인지 판단하고 두번째 인자인 SystemInformation 버퍼를 통해 결과를 보여준다.

(또 NtQuerySystemInformation은 두번의 호출로 값을 얻어오기도 하는데 방식은 4번째 인자가 있고 없고의 차이가 있다. 있으면 Information 크기를 얻어오고, 없으면 Information 크기로 값을 얻어오는 것 같다. 더 확인이 필요함....그러니깐 4번쩌 인자가 들어갔을 때 그 크기를 구해오는 거고 크기를 바탕으로 다시한번 함수를 호출하는 방식으로 정보를 얻는 것..)

NtQuerySystemInformation으로 SystemModuleInformation정보를 얻고자 할 때, 로드되는 메모리 구조는 다음과 같다.

위의 이미지를 예로 들면 ntkrnlpa.exe의 IMG_BASE는 '804d9000'이 되겠다.

활용하자면 NtQuerySystemInformation의 SYSTEM_MODULE_INFORMATION으로 로드된 모듈과 img base, 또는 로드된 모듈 개수, 또는 커널 이미지 정보를 확인 가능하다.

#PlugX Malware

보통의 경우 최초 드럽퍼가 실행되면 exe, dll, data 파일(확장자는 제작자 마음) 이렇게 3종류의 파일이 특정 폴더에 설치가 된다. 최초 드럽퍼가 어떻게 실행되는 지 확인하지 못 했지만, 방법이야 다양하니 생략,,

예) 

C:\Program Files\Common Files\Nv.exe

C:\Program Files\Common Files\NvSmartMax.dll

C:\Program Files\Common Files\NvSmart.mp3

같은 폴더에 나란히 3가지 파일이 설치되면 먼저 exe파일이 실행되고 DLL이 로드되며 해당 DLL이 다시 남은 data 파일(위의 NvSmart.mp3)을 로드하는 방식이다. 설치를 위해 각각의 파일이 반드시 존재해야하는 것이다.

그런데 3가지 파일이 반드시 필요한 이유가 더 있다. 자세히 살펴보면...

일단 DLL 파일의 Main코드를 살펴보면 다음과 같은 코드들을 볼 수 있다.

처음부터 '20120101'을 현재 실행되고 있는 PC의 System시간과 비교한다. 이 부분은 상기 언급한 반드시 필요한 부분에 포함되지 않지만, 구지 비교하는 이유가 궁금해서.. 이유가 뭘까. 

위 그림을 보면 Module EP를 찾아서 EP의 Page를 R/W하게 변경한다. 그리고 다음과 같이 하드 코딩된 주소(_DataLoad_Routine_)와 EP의 거리를 계산해서 Module EP부분에 덮어쓴다. 해당 어셈코드는 "E8 A6 18 00 00"에서 "E8 8A F8 8F 0F"로 변경되면서 점프되는 곳이 _DataLoad_Routine_ 주소로 바뀌는 것이다.

[Dll Main 코드에 삽입된 EP 수정 코드]

(귀찮게...)

어쨌건 정리하면, exe는 쓰고자하는 DLL을 import하고..

[exe의 import table중 일부]

DLL이 로드되면 DLL Main코드가 실행되면서 exe의 EP가 수정되며(exe 시작전) 다시 DLL의 특정 주소로 점프가 된다(exe 시작 직후). exe는 dll 실행히켜주고 dll은 exe 수정해주고 다시 exe는 dll을 통해 data 파일을 호출하는...완벽한 호흡을 자랑한다..;;

[exe의 원래 EP 코드]

그리고 첨부해서.. exe 원래 EP 코드를 보면 CRTStartup 보다 먼저 어떤 Call이 실행 되는 것을 볼 수 있다. 그래서 exe를 그냥 메인코드 먼저 디버깅하거나 IDA같은 Disassembler로만 보면 놓치는게 있을 수도..

정말 독일은 꼭 가봐야겠다.

http://www.youngsamsung.com/travel.do?cmd=view&seq=63658