posted by 블르샤이닝 2013. 5. 23. 17:21
728x90
엑셀파일만 해당된다. 





xlsview.zip



Another_OLE_Doc_Viewer_src.zip


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

근데 엑셀 매크로 바이러스는 엑셀을 실행해서 alt + F11 키 누르면 VBA(매크로 함수 기능) 코드 확인가능하다....누가 자꾸 엑셀 찾아보는것같은데 엑셀 자체 프로그램으로 분석하고 만약 잠겨있다면 그때 엑셀 파일에 대한 파일 내부의 구조를 보는게(근데 암호화되면 확인이 안된다고 보는게 편하다) 좋다. 이상 끝

728x90
posted by 블르샤이닝 2013. 5. 10. 10:38
728x90

오랜만에 DOC 매크로 바이러스가 외국에서 출몰하여 분석중에 좋은정보들이 있어서 가져온다~


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

흔히 Compound Document File(CDF) 포맷을 가지는 파일을 분석할 경우 그 동안 MiTeC에서 개발한 Structed Storage View(SSView)를 사용해 왔다. CDF 포맷을 가지는 파일들은 XLS, PPT, DOC(98~2003), HWP 등을 의미한다. 다들 원래 CDF 포맷과는 조금 다르게 자기들만의 방식으로 변경하여 사용하고 있지만 기본적인 내용은 그대로 유지되어 사용된다.

다음은 SSView를 통해 doc 파일의 구조를 살펴본 것이다. 각 파일 포맷의 Storage 별로 내용을 파싱해 보여준다.

최근에 Microsoft에서 OLE 형식의 구조를 살펴 볼 수 있는 OffVis(Office Visualization Tool) 를 발표했다. 얼마전에 MCDF(Microsoft CDF), OOXML(Open Office XML) 문서 포맷에 대해서 각 문서(.doc(x), .xls(x), .ppt(x))별로 백장이 넘는 상세 포맷 문서를 공개한적이 있다. 물론 문서를 살펴보면 생략한 부분이 많이 있지만 그동안 꼭꼭 숨겨왔던 것과는 대조로 공개하기 시작했다.

게다가 해당 문서의 구조를 살펴볼 수 있는 OffVis까지 공개하다니 참 이례적인 일이다. 아마도 자신들의 문서와 관련된 많은 보안문제가 발생하면서 공개하려는 마음을 먹은듯 하다. OffVis의 주 목적은 MCDF 내에 숨길 수 있는 악의적인 스크립트나 데이터들을 확인하기 위한 것이다. 만약 구조를 벗어난 데이터가 삽입되어 있다면 해당 데이터를 쉽게 확인할 수 있다. 다음 자료는 MCDF 포맷에 악의적인 데이터 삽입에 관해 발표된 내용이다.
http://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-Dang/BlackHat-Japan-08-Dang-Office-Attacks.pdf

OffiVis는 다음과 같이 8개의 Office 파일의 취약성을 파싱해준다.

CVEProductBulletin
CVE-2006-0009PowerPointMS06-012 (March 2006)
CVE-2006-0022PowerPointMS06-028 (June 2006)
CVE-2006-2492WordMS06-027 (June 2006)
CVE-2006-3434WordMS06-062 (October 2006)
CVE-2007-0671ExcelMS07-015 (February 2007)
CVE-2008-0081ExcelMS08-014 (March 2008)
CVE-2009-0238ExcelMS09-009 (April 2009)
CVE-2009-0556PowerPointMS09-017 (May 2009)

 

다음은 OffVis를 통해 위의 SSView에서 확인했던 doc파일을 열어본 것이다.


OffVis는 Office 파일의 취약성을 테스트하기 위해 개발되었지만 SSView보다 더 자세하게 트리 구조로 해당 파일 포맷의 구조를 표현해준다는 점에서 해당 파일을 분석하는데 큰 도움이 된다. 그 동안 각 구조를 HexWorkshop을 통해 일일이 Bookmark 하면서 따라갔던 고생이 한번에 해결된 것이다. 이런 좋은 도구가 좀 일찍 나왔으면 좋았을텐데… ^^

OffVis는 다음의 주소에서 다운받을 수 있다.
http://www.microsoft.com/presspass/press/2009/jul09/07-27BlackHat09PR.mspx



Malicious Document Analysis(by ariesike).pdf



728x90
posted by 블르샤이닝 2013. 4. 26. 11:29
728x90

이가없으면 잇몸으로..우선 mac분석 기반이(맥 제품 사고싶어!!!) 없으니 윈도우에서 몇가지 보면 알수 있는 방법. 걍 winhex로 매크로 부분 확인





728x90
posted by 블르샤이닝 2013. 4. 3. 16:48
728x90

시작전에 파일을 감염시킨후 windows가 올라오기전 windbg로 정지시키고 해당 드라이버에 bp를 건다.

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


드라이버 분석.rtf

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

출처 : http://muhan56.tistory.com/66

DriverEntry - 드라이버 시작점 부터 디버깅 하기

드라이버(.sys)파일의 시작점(Entry-Point)부터 디버깅 하는 방법 입니다. 커널 디버깅 환경이 준비 되어야 하며 분석대상 드라이버 PDB 파일의 유무에 따라 분석 방법이 조금 달라 집니다. 먼저 디버기 시스템(Virtual PC 2007)에서 드라이버를 등록(Register Service)하고 나서 디버거(WinDBG)에 입력되는 명령어는 아래와 같습니다. [예제 드라이버 소스코드 경로]

 

1. 디버깅 대상 드라이버 파일의 PDB 있을 경우

nt!RtlpBreakWithStatusInstruction:
804e3592 cc              int     3
kd> sxe ld cr0.sys          // cr0.sys 드라이버 로드 시점에 BP 설정
kd> g
nt!DebugService2+0x10:
80506d3e cc              int     3          // BP가 걸렸습니다 (cr0.sys 드라이버 로딩)
kd> lm
start    end        module name
7c900000 7c9b2000   ntdll      (pdb symbols)
...
f8c8a000 f8c8a800   cr0        (private pdb symbols)     // cr0.sys pdb 확인
kd> bp cr0!DriverEntry          // cr0.sys 코드시작(DriverEntry)점에 BP 설정
kd> bl
 0 e f8c8a4c0     0001 (0001) cr0!DriverEntry
kd> g
Breakpoint 0 hit
cr0!DriverEntry:          // BP가 걸렸습니다 (DriverEntry)
f8c8a4c0 8bff            mov     edi,edi
kd> u
cr0!DriverEntry [c:\sdt_cr0\set_cr0.cpp @ 22]:
f8c8a4c0 8bff            mov     edi,edi
f8c8a4c2 55              push    ebp
f8c8a4c3 8bec            mov     ebp,esp
f8c8a4c5 6810a5c8f8      push    offset cr0! ?? ::FNODOBFM::`string' (f8c8a510)
f8c8a4ca e825000000      call    cr0!DbgPrint (f8c8a4f4)
f8c8a4cf 83c404          add     esp,4
f8c8a4d2 8b4508          mov     eax,dword ptr [ebp+8]
f8c8a4d5 c7403490a4c8f8  mov     dword ptr [eax+34h],offset cr0!OnUnload (f8c8a490)
kd> db f8c8a510          // DbgPrint 인자값 확인
f8c8a510  44 72 69 76 65 72 45 6e-74 72 79 28 29 20 53 74  DriverEntry() St
f8c8a520  61 72 74 0a 00 00 00 00-00 00 00 00 00 00 00 00  art.............
f8c8a530  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8c8a540  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8c8a550  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8c8a560  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8c8a570  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8c8a580  00 20 55 80 79 f0 4f 80-00 00 00 00 00 00 00 00  . U.y.O.........


2. 디버깅 대상 드라이버 파일의 PDB 없을 경우

nt!RtlpBreakWithStatusInstruction:
804e3592 cc              int     3
kd> sxe ld cr0.sys          // cr0.sys 드라이버 로드 시점에 BP 설정
kd> g
nt!DebugService2+0x10:
80506d3e cc              int     3          // BP가 걸렸습니다 (cr0.sys 드라이버 로딩)
kd> lm
start    end        module name
7c900000 7c9b2000   ntdll      (pdb symbols)
...
f8b84000 f8b84800   cr0        (deferred)          // cr0.sys pdb 없음
kd> bp cr0!DriverEntry
*** ERROR: Module load completed but symbols could not be loaded for cr0.sys
Couldn't resolve error at 'cr0!DriverEntry'          // DriverEntry 지점에 BP를 걸 수 없습니다
kd> u f8b846be          // cr0 start address(f8b84000) + cr0 Address Entry Point(6be)
cr0+0x6be:
f8b846be 8bff            mov     edi,edi
f8b846c0 55              push    ebp
f8b846c1 8bec            mov     ebp,esp
f8b846c3 e8bdffffff      call    cr0+0x685 (f8b84685)
f8b846c8 5d              pop     ebp
f8b846c9 e9f2fdffff      jmp     cr0+0x4c0 (f8b844c0)
f8b846ce cc              int     3
f8b846cf cc              int     3
kd> bp f8b844c0          // cr0.sys 코드시작(DriverEntry)점에 BP 설정
kd> bl
0 e f8b844c0     0001 (0001) cr0+0x4c0
kd> g
Breakpoint 0 hit
cr0+0x4c0:          // BP가 걸렸습니다 (DriverEntry)
f8b844c0 8bff            mov     edi,edi
kd> u
cr0+0x4c0:
f8b844c0 8bff            mov     edi,edi
f8b844c2 55              push    ebp
f8b844c3 8bec            mov     ebp,esp
f8b844c5 681045b8f8      push    offset cr0+0x510 (f8b84510)
f8b844ca e825000000      call    cr0+0x4f4 (f8b844f4)
f8b844cf 83c404          add     esp,4
f8b844d2 8b4508          mov     eax,dword ptr [ebp+8]
f8b844d5 c740349044b8f8  mov     dword ptr [eax+34h],offset cr0+0x490 (f8b84490)
kd> db f8b84510         // DbgPrint 인자값 확인
f8b84510  44 72 69 76 65 72 45 6e-74 72 79 28 29 20 53 74  DriverEntry() St
f8b84520  61 72 74 0a 00 00 00 00-00 00 00 00 00 00 00 00  art.............
f8b84530  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8b84540  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8b84550  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8b84560  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8b84570  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8b84580  00 20 55 80 79 f0 4f 80-00 00 00 00 00 00 00 00  . U.y.O........
.



u : 코드를 페이지식으로 누른다. u를 또 누르면 다음 페이지가 보여진다.
u main : 이 명령어 치면 메인 화면이 보인다.
g : 실행하는 명령어다.

r : 레지스터 값을 보여준다.
p : 스퉵오버
t : 스텝인투

728x90
posted by 블르샤이닝 2013. 4. 2. 09:51
728x90

출처 : http://badcob.tistory.com/entry/vmware-detection


악성코드 샘플을 수집해서 분석하는 중에 Vmware에서 실행을 하려 해도 
제대로 실행이 되질 않는 놈이 있더군요. 몇번 클릭질 해보다 안되겠다 싶어 
트레이싱을 해보니 아무래도 vmware 를 인식하고 알아서 죽는것 같더이다.

그래서 vmware detection 이라는 키워드로 구글링을 한참 해봤지만 
원하는 자료가 쉬이 나오질 않으니, 시간은 점점 흐르고 분석 문서는 작성해야되는데
악성코드를 실행조차 못하는 상황T_T.. 그러던 와중에 원하는 자료를 발견(!)해서 정리해 둡니다.





In instruction에 대한 설명 - http://en.wikibooks.org/wiki/X86_Assembly/Other_Instructions

I/O Instructions

in dest, src

The IN instruction almost always has the operands AX and DX (or EAX and EDX) associated with it. DX (src) frequently holds the port address to read, and AX (dest) receives the data from the port. In Protected Mode operating systems, the IN instruction is frequently locked, and normal users can't use it in their programs.


DX(src)는 읽을 port address를 가지고 있고, AX(dest)는 그 port의 데이터를 받습니다.

위의 코드에서, "in   eax, dx" 가 실행될 때, 
dx에는 0x5658(port address)이, eax에는 0x564D5867 (VMXh)이 들어 있습니다. 

즉  In  0x564D5867, 0x5658  요런 모양으로 실행되겠죠. 

그 후에 ebx의 값을 0x564D5867 과 비교해서 같으면 Vmware 환경에서 작동하는 것으로 판단,
종료 시킵니다. 


참고 사이트  : http://isc.sans.edu/diary.html?storyid=3190


728x90