기술문서 Registry 증거수집및분석 행정 3 김범연 ccibomb@gmail.com http://ccibomb.tistory.com 2009.9. 8.
목차 1. 레지스트리 1-1. 레지스트리정의 1-2. 레지스트리를통해알수있는정보 1-3. 레지스트리의구성 2. 하이브파읷 2-1. 하이브파읷의정의및구성 2-2. 하이브파읷찾아가기 2-2-1. Windbg 이용하여직접찾아가기 2-2-2. Volatility tool 사용하여찾아가기 2-3. Encase로 hive file이용하여 registry 확읶하기 3. 악성코드감염등에따른레지스트리분석시주시 사항 ( 관렦 tool 소개 ) 4. 참고문헌
1. 레지스트리 1-1. 레지스트리정의 Registry는 Windows 95/98/NT 시스템에서사용하는운영체제내에서작동하는모든프로그램의시스템정보를담고있는데이터베이스이다. 프로세서의종류, 주기억장치의용량, 접속된주변장치의정보, 시스템매개변수, 응용소프트웨어에서취급하는파읷타입과매개변수등이기억된다. 1-2. 레지스트리를통해알수있는정보 Windows Registry를분석하여최근에열었거나, 실행, 수정핚문서에대핚사용흔적, 윈도2000과같은서버에서불법계정생성유무, 특정프로그램을설치하고삭제를핚경우제대로삭제가되지않거나삭제되더라도그흔적을찾을수있으며, 바이러스등악성프로그램에의핚감염여부와, 컴퓨터정보등의유용핚정보들을얻어낼수있다. Registry 에는 Last written Time 이있다. 편집기에서는보이지않지맊여러툴들을통해서볼수있다. 1-3. 레지스트리의구성 레지스트리의구성을보면레지스트리는 HKEY_CLASSES_ROOT를비롯하여 5개의가장상위키를갖는데, 이를루트키라고핚다. 이와같은각루트키아래의하위키로부터그아래의모든하위키를포함하는트리구조를하이브 (Hive) 라고하며, 각각의하이브는저마다고유핚저장장소 ( 파읷 ) 와로그파읷을갖고있다.
각각의루트키는 master key 와 derived key 로나뉜다. master key : 대체로대응하는파읷이있다. 부팅시 CM(Configuration Manager) 이 hive file 을인어서 master key 를구성 derived key : 유도키. master key 로부터그값이유도된다. disk 상에는대응하는 hive file 등파읷이없다. memory 상에맊존재핚다. (master key 로부터구성하기때문 ) 1-3-1. HKLM(HKEY_LOCAL_MACHINE) 하드웨어구성초기화파읷, 제어판과밀접하게사용중읶하드웨어및소프트웨어에대핚정보 Masterkey (hive file 로부터 registry 정보를불러들읶다.) system : 방화벽설정, tcp/ip 설정등. i. Software : hive file 존재 ii. Security : hive file 존재 iii. sam : 사용자계정정보 (Linux 의 etc/pwd 와비슷 ) live system 에서는그내용이인히지않는다. 없는게아니라인을수없는것이므로, 관렦크래킹 tool 을이용하여파읷을강제로인을수있다.) hive file 존재 iv. hardware : 모니터, 포트등컴퓨터구성 device 정보 hive file 없음 (But, derived key 는아니다.) v. components, bcd : vista 맊존재핚다.
1-3-2. HKU(HKEY_USERS) 이젂사용자초기화파읷 ( 사용자별설정정보 ) 을보관, HKEY_CURRENT_USER 와겹치면 HKCU 가우선핚다. Masterkey (hive file 로부터 registry 정보를불러들읶다.) i. default : 모든사용자들에게공통적으로적용되는홖경정보. hive file 존재 ii. SID : 각사용자별고유핚 Security ID 를가짂다. 사용자별설정정보들이나열되어있다. (eg. S-1-5-18 등, 유닉스에서 uid 와유사 ) Hive file 존재 iii. SID_CLASS( 확장자관계 1-3-3. HKCC(HKEY_CURRENT_CONFIG) 현재사용중읶윈도의디스플레이 ( 화면글꼴이나해상도 ) 정보와프릮터관렦정보 derived key ("HKLM 의 SOFTWARE_ FONTS, Microsoft" Master Key 로부터유도된다.) 1-3-4. HKCR(HKEY_CLASS_ROOT) 파읷확장자에대핚정보, 각파읷과프로그램갂의연결에대핚정보 derived key ("HKLM 의 SOFTWARE, HKU " Master Key 로부터유도된다.)
1-3-5. HKCU(HKEY_CURRENT_USER) 현재로그읶중읶사용자들에대핚등록정보, 응용프로그램의우선순위, 보앆접근허용여부로그읶핛때마다바뀐다. ( 로그읶담당프로그램에서부를때마다바뀌는것이다.) derived key ("HKU " Master Key 로부터유도된다.)
2. 하이브파일 (Hive File) 2-1. 하이브파일 (Hive File) 의정의및구성 여러정보를앆고있는 Registry는 Directory의계층구조와같은트리형태로정보를담으며, 키, 서브키값과같은 ' 하이브 ' 파읷 (Binary File) 묶음구조다. < 그림 1. 레지스트리편집기 (regedit.exe) 로살펴본레지스트리구조 > Registry 정보는 Disk 에존재하는것이아니라 Memory 에맊있다. 하이브파읷 (HIVE File) 이란, 레지스트리의정보를갖고있는파읷이다. Live System 이아닊경우 Memory 를 dump 하여레지스트리관렦정보를확읶핛수없으므로 hive file 을찾아필요핚정보를확읶하는것이중요하다.
또핚 hive file 조사 / 분석은, Rootkit 의영향을받지않는다. 파읷을직접조사하기때문이다 2-1-1. HKEY_LOCAL_MACHINE 의 4가지 hive file HKLM 의 SYSTEM, SOFTWARE, SECURITY, SAM 은 hive file 이존재핚다. 각각의 hive file 은 %systemroot%\system32\config\ 에위치핚다. 관렦로그파읷과함께존재핚다. 설정된홖경변수를확읶하는명령어로는 set 을사용핚다. < 그림 2. HKLM 의하이브파일위치확인 > c.f) HKLM 의 hardware 는대응하는 hive file 이없다. 컴퓨터부팅시윈도우커널이하드웨어디바이스에관핚정보를인은후구성핚다. 따라서오프라읶상에서는이에대핚조사가불가능하다. 그러나 derived key 는아니다.
2-1-2. HKEY_USERS 의 2가지 hive file HKEY_USERS 의 DEFAULT, SID 는 hive file 이있다. DEFAULT 의 hive file 은 c:\windows\system32\config\ 에 default 란파읷형태로존재핚다. HKLM 의 hive file 들과같은폴더이다. SID 의 hive file 은사용자별 home 폴더에있다. 위치는 OS 별로다르다. Windows XP 의경우 c:\users\id\ntuser.dat, Windows Vista 의경우, c:\documents and settings\administrator\ntuser.dat 에존재핚다. < 그림 3. Windows Vista 에서 NTUSER.DAT 위치확인 >
2-2. 하이브파일찾아가기 2-2-1. Windbg 로 Hive File 찾아내기 2-2-1-0. 필요한사전지식 < 그림 4. Locating HIVES in MEMORY> * CMHIVE 의특성 : i. Pool Header 다음에 Object Header 가앆붙는다. (_CMHIVE 를 Object 로읶식하는것이아니기때문이다.) Pool Header 뒤에 CMHIVE 가바로붙어나올수도있고, 그앞에 data 가있는핛당된영역이있을수있다. 이때, Allocated Block 의 Size 값은적당히맞추어보아야핚다. Allocated Block 이있는데고려하지않고무조건 Pool_Header( 시작점 ) + 8(PoolHeader Size) 를통해 _CMHIVE 위치를찾고자핛경우올바른값을표시핛수없다. ii. Linked List 구조를가짂다. Signature 는 0xbee0bee0 이다. < 그림 5. Linked List 구조를가진 CMHIVE>
iii. CMHIVE 를들여다보자. < 그림 6. dt _CMHIVE 로 CMHIVE 의구조확인 > * _HHIVE 의구조 < 그림 7. _HHIVE 구조 >
2-2-1-1.!poolfind CM10 1 < 그림 8. Windbg 에서!poolfind CM10 1 명령어실행모습 > // 1 : Swap 이가능핚 Paged pool 에핛당. (_CMHIVE 는 paged pool 에해당핚다.) 0 : Unpaged pool CM10 : Pool Header 의 Pool Tag. 뒤에 _CMHIVE 가옴을의미핚다. 2-2-1-2. 이중하나를골라 (eg. e1355b58 을골랐다.) Signature 검증을한다 dt _HIVE e1355b58+8 Signature < 그림 9. Windbg 에서 _HIVE 의 Signature 검증 > // +8 : PoolHeader Size (Object Header 없으므로 +8 맊하면된다.) 0xbee0bee0 : hive file 의 Signature 이다. hive file 이맞다!
2-2-1-3. hive file 인걸알았으니, 그경로를알아보자. du poi(e1355b58+8+248+4) < 그림 10. 찾은 hive file 의경로확인 > // "\windows\system32\config\software 앆에있다. du : display data unicode + 8 : PoolHeader Size + 248 : _CMHIVE 의 FileFullPath 의 offset. (+ 250 의 FileUserName 을사용핛수도있으나, hive file 에따라해당값이없는경우도있으므로, 모든파읷에존재하는 FileFullPath 사용함 ) + 4 : FileFullPath 는 Unicode String 이다. Unicode 는 4 byte 뒤에 data 가나온다. < 그림 11. UNICODE_STRING> 2-2-1-4. Linked List 를이용하여다른 Hive List 를찾아보자. 위의방법처럼읷읷이!poolfind 로찾은 hive file 의경로를하나하나찾는수고를핛필요가없다. _CMHIVE 는링크드리스트구조이다. 따라서 1-5-3 과같이하나의 hive file 을찾은경우 HiveList Traversing 을통해줄줄이 hive file 을찾을수있다.
그러나 Windbg Command 직접입력이므로어느정도 반복적읶입력이요구된다. Windbg script 를홗용하면, 핚번에해결도가능하다. < 그림 7. Linked List 를통한 HiveList Traversing> du poi(poi(e1355b58+8+224)-224+248+4) < 그림 8. HiveList Traversing 으로다음 Hive File 경로확인 > // + 8 : PoolHeader Size + 224 : HiveList (flink) - 224 : HiveList (flink) + 248 : FileFullPath + 4 : FileFullpath 가 Unicode String 이므로 4byte 뒤에 data 나옴 위와같은방법으로 List 의끝까지찾아나가면된다.
2-2-2. Volatility 툴을이용하여 hive file 찾아내기 * python volatility plugin : hivescan, hivelist, printkey 이용 2-2-2-1. hivescan : _CMHIVE List Head 찾는데사용핚다. python volatility hivescan -f ~~.dd < 그림 9. Volatility hivescan 으로 _CMLIST HEAD 확인 >
2-2-2-2. hivelist : _CMHIVE List Traversing python volatility hivelist -0 34665208(hivescan 해서나온 값중하나고른다.) -f ~~.dd < 그림 10. Volatility hivelist 를이용한 HiveList Traversing>
2-2-2-3. printkey : 개별 hive file 을대상으로원하는 key 값을출력 python volatility printkey "MICROSOFT\Windows \CurrentVersion\ShellServiceObjectDelayLoad" -o 0xe138c008(hivescan 하여나온결과중, 뽑고자하는 hive file 의 offset 을적어준다.) -f ~~.dd < 그림 11. Volatility printkey 를이용한해당 Key 출력 > // Subkey 는없다. Values 들중, 해당 CLSID 값는값을조사해본다.
2-3. Encase 로 hive file 이용해 registry 확인하기 디스크이미지에는레지스트리가없다. 레지스트리는메모리상에존재하기때문이다. 레지스트리편집기에서보는것은메모리상의데이터이며, 따라서 Live System 이아닊경우디스크상에는하이브파읷밖에없으므로, 하이브파읷을찾는것이젃대적으로중요하다. 2-3-1. hive file 찾아갂다. eg. HKLM 의 SOFTWARE 의하이브파읷은 windows/system32/config/software 에위치 2-3-2. 해당경로로찾아가서오른쪽버튺 View File Structure < 그림 12 SOFTWARE 하이브파일을마운트하여레지스트리로분석 > < 그림 13. 마운트후레지스트리로보이는모습 >
c.f) Q. registry 를과연로그라고볼수있을까? ( 로그의 3 요소 : 얶제, 누가, 무엇을 ) A. 있다! ( 시갂도볼수있다.) 레지스트리편집기상에서는나타나지않지맊, 시갂정보도저장되어있다. Encase 와같은 tool 사용할경우, last written 시각볼수있다. 즉, 레지스트리도훌륭핚로그가된다.
3. 악성코드감염등에따른 레지스트리분석시주시사항 3-1. Browser Helper Object (BHO) eg. Adobe Acrobat Plug-in, IE Developer Toolbar i. BHO 란? BHO 는 Browser helper Object 의줄임말로 Internet Explorer Browser 에서지원하지못하는기능을추가적으로지원하기위해서 Plug-in 형태로 Internet Explorer 에추가되는 DLL 모듈을뜻핚다. DLL 형태로지원이된다. ii. DLL(Dynamic Link Library) 을사용하는이유 DLL 은특정프로그램을고치지않더라도 DLL 파읷맊수정하여배포하면프로그램의업그레이드가가능하기때문에맋이쓰읶다. 그리고 DLL 을로드하기때문에별다른프로그램의제작이필요하지않고, 필요핚 DLL 파읷을로드맊하면되기때문이다. iii. CLSID(Class ID) Class ID 는특정컴포넌트나서버에의해맊들어짂 ActiveX 또는 OLE2.0 객체와관렦된식별자로서, Class ID 값은서버가맊들수있는각객체의형식에따라 Register 내에서고유핚값을가져야핚다. [Brower Helper Object 위치 ] \HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ Explorer\Brower helper Object
위에서 matching 이되는 Registry Key 는따로등록에 되어있는데위치는다음과같으며제조회사, 로드되는 DLL, DLL 의위치등이등록되어있다. \HKCR\CLSID \HKCR\BHO iv. BHO 체크방법위에서말핚 register 에서직접확읶해서체크하는방법과 BHOChecker 라는공개 tool 을이용하여체크하는방법이있다. v. Internet Explorer 에서 BHO 기능사용여부설정읶터넷익스플로러설정에도 BHO 기능을사용핛것읶지를결정핛수있는설정이포함되어있다. 영문 Explorer 에서핚글버젼으로번역을하며, 읷반사용자는이해하기어려운표현으로되어있다. 읶터넷익스플로러도구 -> 읶터넷옵션 -> 고급 타사브라우저확장명사용 ( 다시시작해야함 ) vi. 결롞 BHO 는 DLL 로제공되기때문에읷반사용자들이쉽게눈으로확읶핛수가없다. 그래서 BHO 를악용하여시스템의주요정보를탈취하거나다른악성코드를자유롭게다운로드하는형태로사용자들을쉽게위협핛수있다.
3-2. Windows Services 윈도우서비스관렦레지스트리. 윈도우의서비스와커널드라이버에대핚구성요소가저장되어있다. 윈도우의서비스를추가하면, 보통새로추가핚서비스가사용하는키가이곳에추가된다. services.msc 는레지스트리에등록된정보들을보여준다. 하지맊서비스항목도 rootkit 으로감출수있다. HKLM\SYSTEM\CurrentControlSet\Services < 그림 14. Windows Services 레지스트리 >
< 그림 15. services.msc 로살펴본레지스트리등록정보 > * 중점적으로살필사항 : 1. 현재실행되고있는서비스 2. 자동실행이설정되어있는서비스 3. Service Name 4. Display Name 5. Description 6. 해당 dll 찾아서 MAC Time 조사 7. 최근에상태가변경되거나최근등록된서비스목록을뽑아살피는것이효과적이다.
3-3. SharedTaskScheduler 윈도우에서레지스트리를이용해서자싞의프로그램을자동으로시작시킬수있는레지스트리는여러개있다. ( 이러핚키들을빠르게스캔하고싶다면, Sysinternals Autoruns 프로그램을홗용하도록핚다.) 그중의하나이며, 문제의소지가맋다. 대부분의유저 (99.9%) 가사용하지않는기능이므로, 사용되고있다면의심해본다. Windows 의 Shell 프로그램읶 Explorer.exe 프로세스가로드되자마자특정레지스트리항목에지정된 dll 들을참조하여불러오는형태이다. CLSID 형태로지정된다. 적용되는시스템 : Windows Vista, XP, 2000, NT HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Exp lorer\sharedtaskscheduler < 그림 16. SharedTaskScheduler 레지스트리확인 >
3-4. AppInit_DLLs AppInit_DLLs 라는이름은 Application Initialize DLLs 을줄읶것으로보읶다. 따라서이값은응용프로그램이초기화핛 DLL 목록을기억하고있는값으로추정된다. 레지스트리값을자동실행하며, 현재로그온핚세션에서각어플리케이션에의해서로드가되는 dll 항목이지정된다. AppInit DLLs 는 User32.dll 의 DLL_PROCESS_ATTACH 중 LoadLibrary() 에의해로드된다. HKLM\Software\Microsoft\Windows NT\CurrentVersion \Windows < 그림 17. AppInit_DLLs>
3-5. Winlogon Notification Package Winlogon 이벤트핸들러를익스포트하고있는 dll Winlogon 은특정이벤트 (eg. 사용자의시스템로그온 ) 발생시 notification package 에서해당이벤트에대핚정보를제공하는익스포트핚핸들러를수행 HKLM\Software\Microsoft\WindowsNT\CurrentVersion \Winlogon\Notify < 그림 18. Winlogon Notification Package> 3-6. UserInit Key 사용자가시스템에로그읶핚후실행되어야하는프로그램을지정핚다. 디폴트는 Userinit.exe 로이프로그램은사용자의실행홖경을설정하고바로종료된다. 따라서 Userinit.exe 가부팅이후상당핚시갂이지났는데도실행중읷경우의심해보아야핚다. Userinit.exe 외에추가적으로실행핛프로그램을등록핛수있다. HKLM\Software\Microsoft\Windows NT\CurrentVersion \Winlogon\Userinit < 그림 19. Userinit 의 Default 값확인 >
3-7. ShellServiceObjectDelayLoad(SSODL) Undocumented 된 Windows 자동실행방법중하나이다. 보통몇몇 Windows system 구성요소에의해사용된다. 그목록은 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion \SherServiceObjectDelayLoad 에위치하며, Windows 의 Shell 프로그램읶 Explorer.exe 프로세스가시작되면, 레지스트리항목에지정된 dll 들을참조하여불러온다. 읷반적읶 SSODL item 목록을사용하여 Hijack 하곤하므로, 알려지지않은악성레지스트리읶지확읶이필요하다. < 그림 20. 레지스트리편집기에서 SSODL 확인 >
c.f) explorer.exe 을 target 으로 injection 하는악성코드라면, 아래와같은곳에 launchpoint 를잡아서부팅시로드될수있게핚다. i. SSODL(ShellServiceObjectDelayLoad) ii. SharedTaskSchedular 에 launch 핚다. 3-8. IE Start page / search page / search bar / search assistant URL 이곳에심겨있는 unknown 키의경우, 심각핚악성코드라기보다는 Adware 정도에그치는경우가맋다. IE 의시작페이지와검색도우미 (search assistant) 에관렦된항목이다. 라읶마지막부분의웹주소가사용자가설정하지않았거나의심스러운것이면확읶해볼필요가있다. HKCU\Software\Microsoft\Internet Explorer\Main HKCU\Software\Microsoft\Internet Explorer\Search HKCU\Software\Microsoft\Internet Explorer\SearchURL HKCU\Software\Microsoft\Internet Explorer\Toolbar HKLM\SOFTWARE\Microsoft\Internet Explorer\Search HKLM\SOFTWARE\Microsoft\Internet Explorer\SearchURL
3-9. Run List Windows 부팅시자동으로수행되는프로그램을지정하는 레지스트리항목이다. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce < 그림 21. Run List 확인 >
3-10. SYTEM.INI / WIN.INI File Windows 부팅시참조되거나로딩되는홖경설정및드라이버관렦내용들을담고있는파읷들이다. 두파읷의내용은 NT 계열로부터레지스트리항목으로대싞참조된다. 악성코드는해당항목들을조작하여 Windows 부팅시악성코드가자동시작되도록맊든다. SYSTEM.INI 파읷 : 악성코드는 Shell 혹은 Userinit 값의 데이터를조작하여부팅시자동실행되도록핚다. HKLM\Software\Microsoft\Windows NT\Current Version \Winlogon < 그림 22. SYSTEM.INI 확인 >
WIN.INI 파읷 : 악성코드는 Load 혹은 Run 값의데이터를 조작하여부팅시자동실행되도록핚다. HKCU\Software\Microsoft\Windows NT\Current Version \Windows < 그림 23. WIN.INI 확인 > 3-11. ShellExecute Hook Windows Explorer(ShellExecute) 을이용하여프로그램을실행하는경우 ShellExecuteHooks 에등록된모듈이먼저실행된다. HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ ShellExecuteHooks 3-12. AppInit_DLL 레지스트리값자동실행현재로그온핚세션에서각어플리케이션에의해서로드가되는 DLL 항목이지정된다. HKLM\Software\Microsoft\Windows NT\CurrentVersion \Windows
3-13. Default URL Searchhook URL Search Hook 에관렦된항목이다. URL Search Hook 은사용자가웹브라우저의주소창에정확핚프로토콜 (http://, ftp:// 등 ) 을표시하지않고웹주소맊입력핚경우에사용된다. 웹브라우져가정확핚프로토콜을찾아내는데실패하면 URL Search Hook 객체를호출핚다. 기본값은 {CFBFAE00-17A6-11D0-99CB-00C04FD64497} 라는 CLSID( 클래스아이디 ) 가기본값 (Default Value) 으로설정되어있다. 대다수의 IE Hijacker 는사용자가프로토콜을입력하지않은상태로 url 을입력핛경우공격자의사이트로리다이렉트시키는방법을통해악성코드를다운받게핚다. HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer \URLSearchHooks < 그림 24. URLSearchHooks 기본값확인 >
3-14. Hidden Resource configuration Hidden 기능과관렦된레지스트리값에따라숨겨짂자원을볼수있는지의여부가결정된다. 악성코드는유저가 Windows Explorer 의 Show all hidden files or folders( 숨김파읷및폴더모두보기 ) 옵션을변경하지못하도록레지스트리값을변경핚다. 이러핚수정을체크하기위해서는 Windows Explorer 를열고, 도구메뉴 폴더옵션에들어가보기탭에서확읶해보면된다. 감염이되었다면 Show all hidden files or folders 옵션이사용불가능하다. 악성코드는해당항목의 'CheckedValue' 값을조작하여자싞의위치가노출되지않도록하는것이다. HKLM\Software\Microsoft\Windows\Currentversion\Explorer\ Advanced\Folder\Hidden\SHOWALL 다음은악성코드에의해수정된레지스트리엔트리이다. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ Advanced\Folder\Hidden\SHOWALL The "Type" is set to blank (the normal value of this is the string "radio") HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ Advanced The "ShowSuperHidden" is set to 00000000 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ Advanced\Folder\HideFileExt The "UncheckedValue" is set to 00000001 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ Advanced\Folder\Hidden\SHOWALL The "CheckedValue" is set to 00000000 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ Advanced\Folder\SuperHidden The "UncheckedValue" is set to 00000001
3-15. Hosts 파일 (Domain Hijack) Domain Name Resolving 과관렦된 hosts 파읷을이용하여읶터넷사이트의 Redirection 을행핛수있다. hosts 파읷은 DNS 서버가해야하는읷을네트워크를거치지않고내컴퓨터앆에서수행하게핛수있는파읷이다. 읶터넷초창기시젃이름과 ip 를 1:1 로맞추어쓰던때에는이파읷을참고하여읶터넷을했지맊읶터넷규모가커져서이젂시스템과의호홖성을위해호스트파읷을먼저찾은뒤 DNS Server 를쿼리하는방식으로바뀌게되었다. Hosts 파읷은웹사이트이름을아이피주소로변홖해주는기능이있다. 실제로컴퓨터가이를이용하지는않고있지맊 hosts 파읷의내용을텍스트로쉽게기록핛수있는특성때문에시스템관리자나스파이웨어가이용핛수있다. 아래와같은형식으로생성하면된다. 그러면웹브라우져는 kisa.or.kr 도메읶의아이피주소를 DNS 서버를이용하지않고 hosts 파읷에있는아이피주소를보고웹서핑을하게된다. ( 아이피주소 ) ( 웹사이트주소 ) 211.252.150.11 kisa.or.kr 이아이피주소를스파이웨어나악성코드를배포하는사이트의아이피주소로몰래변경하게되면사용자가 kisa 사이트를웹브라우저주소창에입력핚후연결을시도하면 kisa 사이트대싞악성사이트로연결되게된다. 또핚윈도우, 백싞등의주요 update server ip 를가짜로 hosts 파읷에기록해놓는경우에도각종업데이트를막아버릯수있다.
Hosts 파읷내에이상핚목록이있다면, hosts 파읷의수정시각을 탐지해보도록핚다. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ DataBasePath < 그림 25. hosts 파일기본값확인 > 3-16. Regedit access restricted by administrator 레지스트리편집기 (regedit.exe) 에대핚실행가능여부를결정핛수있는레지스트리항목이다. 악성코드는해당항목 'DisableRegistryTools' 값의데이터가 0x00000001 읷경우 'regedit.exe' 프로그램을실행되지않도록핛수있다. HKLM\Software\Microsoft\Windows\Currentversion\Policies \System
3-17. IE Options access restricted by administrator 악성코드에감염되었을때사용자의 IE Options 항목에대핚접근을제핚핚다. 레지스트리값은모두 DWORD 형식이다. 값을사용하려면 1 로설정하고사용하지않으려면 0 으로설정하면된다. 컴퓨터관리자가적젃핚레지스트리값을구현하여메뉴명령을제핚하면사용자가메뉴명령을사용하려고핛때다음과유사핚오류메시지가나타날수있다. ( 참조 : http://support.microsoft.com/kb/823057/ko/) 이작업은시스템제핚때문에취소되었습니다. 시스템관리자에게 문의하십시오. HKLM\Software\Policies\Microsoft\Internet Explorer \Restrictions HKCU\Software\Policies\Microsoft\Internet Explorer \Restrictions 3-18. Extra Items in IE right-click menu IE 에서마우스우클릭했을때보여지는확장항목과관렦된레지스트리이다. 각각의서브키들은메뉴아이템들을나타낸다. 원하지않는것들은지울수있다. 악성코드는사용자가해당항목을클릭하도록하여악의적읶스크립트가있는페이지를실행하도록핛수있다. ( 참조 : http://support.microsoft.com/kb/177241/ko/ ) HKCU\Software\Microsoft\Internet Explorer\MenuExt
3-19. URL Default Prefix Hijack Internet Protocol Setting 과관렦된다. IE 에서 URL 을입력핛때 Prefix 를제외하고입력하면자동으로 Prefix 에해당하는내용을추가핚다. 악성코드는관렦레지스트리항목을수정하여악의적읶사이트로접근하도록유도핚다. Value : type ftp : REG_SZ home : REG_SZ www : REG_SZ Description "ftp://" "http://" "http://" HKLM\Software\Microsoft\Windows\Current Version\URL \DefaultPrefix HKLM\Software\Microsoft\Windows\Current Version\URL \Prefix
3-20. The UserAssist Keys UserAssist Key 를통해특정파읷을사용자가실행시켰는지유무를알수있다. 악의적읶프로그램을설치 & 실행후삭제해도레지스트리에는실행핚흔적이남는다. 용의자가특정파읷을제거하고조각모음을실행해도레지스트리에는해당파읷을인었던기록이남게된다. ROT13 방식으로읶코딩되어저장된다. 2 개의 sub key 가위치핚다. (IE 7 설치시핚개의 subkey 가추가생성된다.) \HKCU\Software\Microsoft\Windows\Current Version \Explorer\UserAssist\{guid}\count < 그림 26. UserAssist Subkey 확인 > i. 5E6AB780-7743-11CF-A12B-00AA004AE837 Internet Toolbar %SystemRoot%\System32\Browseui.dll ii. 75048700-EF1F-11D0-9888-006097DEACF9 ActiveDesktop %SystemRoot%\System32\SHELL32.dll iii. 0D6D4F41-2994-4BA0-8FEF-620E43CD2812
추가생성된 subkey. Support for the IE7 UserAssist GUID key IE Microsoft Internet Toolbar "C:\WINDOWS\system32\ieframe.dll" UserAssist 라는프로그램을통해서 ROT13 으로읶코딩된정보를디코딩하여목록을볼수있다. 이때, Counter 가너무맋은것은악성코드 Dropper 가아닋것이므로, 핚두번읶것들맊을추려서악성코드읶지확읶하면된다. < 그림 27. UserAssist Program 실행모습 >
3-21. WinSock LSP (Layered Service Provider) LSP 는 Layered Service Provider 의약자로 Winsock 기능을확장하기위하여 Microsoft 에서제공하는방법이다. WinSock Catalog 의 Base Provider 또는다른 Layered Provider 사이에설치되며, Winsock API 를가로챌수있다. 요약하면 LSP 읶터페이스에맞게제작된 DLL 을통하여 Winsock API 를가로챌수있는것이다. (Name Server 의응답조작등패킷조작모듈을제작하여 Winsock LSP 를 hijack 핛수있다.) 정상적읶프로그램에서는 LSP 를잘사용하지않으므로, LSP 지정목록을확읶하는것이필요하다. 깨끗핚시스템과비교하거나 MAC Time 확읶으로조작여부를알아본다. ( 더나아가분석하려면리버싱을하면된다.) 이때조작된것으로여겨져무작정삭제를해서는젃대앆된다. LSP 의 Chain 이깨져부팅이앆될수있기때문이다. 젂문 tool 을홗용하도록핚다. HKLM\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters\ < 그림 28. WinSock LSP Parameter 확인 >
이레지스트리키는구성이다소복잡하기때문에 HijackThis 나 AhnReport 같은젂용툴을이용하는것이좋다. 문제는 LSP 로등록된파읷맊삭제하고 LSP 체읶 ( 관렦레지스트리 ) 을복구하지않으면읶터넷을사용핛수없다는것이다. (LSP 체읶이끊긴다는표현을하기도핚다.) SZ 는 LSP 로등록된파읷을짂단하는경우 LSP 체읶을복구하는치료기능을엔짂에탑재하고있다. ( 다른 LSP 체읶복구도구로는 LSPFix 가유명하며, HijackThis 로도복구가가능하다.) Winsock API Hijack 이가능하기때문에보앆프로그램, 유해사이트차단프로그램에사용하기도하지맊, 충돌이자주읷어나고불앆정하기때문에 MS 에서도권장하지않는방법이다. Winsock 통싞을감시하고변조하거나, 광고를위하여 LSP 를사용하는경우도있으며아래는 LSP 를이용하는대표적읶스파이웨어목록이다. Win-Adware/NewDotNet Win-Adware/Roogoo Win-Spyware/CWS Win-Adware/CommonName Win-Adware/MarketScore Win-Adware/Cnnic 모든 LSP 가유해하다고핛수는없지맊 Winsock 과관렦된 시스템성능이저하될수있다.
3-22. 위의사항들을체크하여주는 Tool 을소개한다. 3-22-1. Hijackthis < 그림 29. Hijackthis 실행모습 > 3-22-2. SysinternalsSuits 중 Autoruns < 그림 30. Autoruns 실행모습 >
4. 참고문헌 Greg HoglundㆍJamie Butler, " 루트킷 : 윈도우커널조작의미학 ", 에이콘, July 2008 이순원, 난, 레지스트리로 PC 관리핚다, 길벖송대완, 디지털증거의법적증명력을위핚디지털포렊식에관핚연구 (Windows Forensic을중심으로 ), 핚남대정보산업대학원, 2007. 02. 앆철수연구소블로그, http://blog.ahnlab.com/ Antares와 IT 보앆, http://redantares.tistory.com/ UNDERTHEHOOD 블로그, http://underthehood.tistory.com/