csrss.exe·smss.exe·wininit.exe·winlogon.exe·services.exe 는 무엇인가 — 부팅 순서와 부모 관계, csrss 가 두 개인 이유

작업 관리자 세부 정보 탭을 PID 순으로 정렬하면 맨 위쪽에 이름이 짧은 프로세스들이 몰려 있다. smss.exe, csrss.exe, wininit.exe, winlogon.exe, services.exe. 사용자 이름 열은 대부분 SYSTEM 이고, 메모리는 몇 MB 에 CPU 는 0이다. 아무도 실행한 적 없는데 늘 그 자리에 있는 이 다섯 개가 지난 편의 lsass.exe 를 띄운 집안이다.

부팅 후 9초 동안 생긴 일

생성 시각과 부모 번호를 한 번에 뽑으면 부팅 순서가 그대로 보인다.

Get-CimInstance Win32_Process |
    Where-Object Name -in 'smss.exe','csrss.exe','wininit.exe','winlogon.exe','services.exe','lsass.exe' |
    Sort-Object CreationDate |
    Select-Object Name, ProcessId, ParentProcessId, SessionId, CreationDate

이 PC 의 시스템 로그에는 운영 체제 시작 시각이 20시 35분 49초로 남아 있었다. 그 뒤를 정리하면 이렇다.

눈여겨볼 것은 "이미 끝난" 부모들이다. csrss 와 wininit, 그리고 다른 csrss 와 winlogon 의 부모 번호는 각각 1388, 1692 였는데 그 번호의 프로세스는 지금 없다. 남아 있는 smss.exe 는 PID 892 하나뿐이다.

smss 가 세션마다 분신을 만든다

smss.exe(Windows 세션 관리자)는 커널이 띄우는 첫 사용자 모드 프로세스다. 레지스트리 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager 의 BootExecute 값(이 PC 에서는 autocheck autochk *, 디스크 검사 예약 확인)을 먼저 처리하고, 페이지 파일과 환경 변수를 준비한다.

그다음 세션을 만든다. 세션 0은 서비스용, 세션 1은 첫 번째로 로그인하는 사용자용이다. smss 는 세션마다 자기 복사본을 하나씩 띄우고, 그 복사본이 그 세션의 csrss 와 wininit 또는 winlogon 을 띄운 다음 스스로 끝난다. 1388 과 1692 가 바로 그 사라진 분신으로 보인다. 원래 smss 는 새 세션이 필요할 때를 위해 남아 있다. 이 PC 의 smss 는 작업 집합 0.1MB, 스레드 2개로 거의 잠들어 있었다.

세션 0에는 wininit, 세션 1에는 winlogon 이 붙는다는 점이 둘을 가르는 기준이다. 서비스와 사용자 화면을 다른 세션에 두는 이 구조는 Windows Vista 부터의 "세션 0 격리"로 알려져 있다. 서비스가 사용자 바탕 화면에 창을 띄워 공격 통로가 되던 문제를 막으려는 설계다.

csrss 가 두 개인 이유

csrss.exe(Client Server Runtime Process)는 세션마다 하나씩 있다. 그래서 세션 0과 1, 두 개가 정상이다. 원격 데스크톱으로 다른 사용자가 들어오거나 사용자 전환으로 두 번째 계정이 로그인하면 세션 2의 csrss 가 하나 더 생긴다.

csrss 는 Win32 하위 시스템의 사용자 모드 쪽이다. 레지스트리 Session Manager\SubSystems 의 Windows 값에 C:\WINDOWS\system32\csrss.exe ObjectDirectory=\Windows ... 처럼 실행 방법이 적혀 있다. 프로세스와 스레드 생성 알림, 종료 처리 같은 일을 맡고, 예전에는 콘솔 창 그리기도 했다. 그 일이 conhost.exe 로 옮겨 간 이야기는 1시즌에 썼다. 메모리는 세션 0 쪽이 개인 메모리 2.9MB, 사용자 세션 쪽이 27.5MB 로 사용자 쪽이 더 컸다. 화면이 있는 세션이라 할 일이 더 많은 것으로 보인다.

wininit, winlogon, services 의 분업

wininit.exe(Windows 시작 응용 프로그램)는 세션 0의 관리인이다. 이 PC 에서 wininit 아래에는 services.exe, lsass.exe, LsaIso.exe, fontdrvhost.exe 네 개가 있었다. 서비스 관리자와 보안 기관을 띄우고 나면 거의 할 일이 없어서 스레드 2개, 개인 메모리 1.7MB 였다.

winlogon.exe(Windows 로그온 응용 프로그램)는 사용자 세션의 관리인이다. 로그인 화면, Ctrl+Alt+Del 화면, 잠금 화면을 띄우고, 로그인이 끝나면 레지스트리 Winlogon 키의 Userinit 값(C:\WINDOWS\system32\userinit.exe,)을 실행한다. userinit 은 로그인 스크립트를 처리하고 Shell 값의 explorer.exe 를 띄운 뒤 끝나는 것으로 알려져 있다. 이 PC 에서도 탐색기의 부모 번호(12432)에 해당하는 프로세스는 이미 없었다. winlogon 아래에는 dwm.exe 와 fontdrvhost.exe 가 붙어 있었다. 화면 합성을 맡는 dwm.exe 도 winlogon 이 띄운다.

services.exe(서비스 및 컨트롤러 응용 프로그램)는 이름 그대로 서비스 관리자다. 확인한 시점에 이 PC 에는 서비스가 337개 등록되어 있고 160개가 실행 중이었다. services.exe 의 자식 프로세스는 151개였는데, 그중 104개가 svchost.exe 였다. 나머지는 Defender 처럼 자기 실행 파일을 가진 Windows 서비스와, 드라이버·금융 보안 프로그램처럼 설치한 프로그램이 등록한 서비스였다. 서비스가 늘 SYSTEM 사용자로 보이는 것도 이 부모 때문이다.

끌 수 없는 이유와 가짜 구별

다섯 개 모두 Windows 가 "핵심 프로세스"로 지정해 둔 것으로 알려져 있다. 관리자 권한으로 csrss 나 wininit 을 강제로 끝내면 Windows 는 계속 돌 수 없다고 보고 CRITICAL_PROCESS_DIED 블루스크린으로 멈추고, 그래서 작업 관리자도 끝내기 전에 경고부터 띄운다. 이 PC 에서 직접 시험해 보지는 않았다. 이 프로세스들이 CPU 를 오래 쓰는 일도 드물다. 사용자 세션의 csrss 가 계속 바쁘다면 프로세스를 아주 빠르게 만들고 끝내기를 반복하는 프로그램이 있는지 보는 편이 낫다.

가짜는 위치와 부모로 걸러진다. 다섯 개 모두 경로가 C:\Windows\System32 이고, 파일 서명은 Microsoft Windows 로 유효해야 한다. 이 PC 에서는 다섯 파일 모두 버전 10.0.26100.9949, 서명 Valid 였다. 크기는 csrss.exe 가 38,576바이트로 가장 작고 winlogon.exe 가 999,424바이트로 가장 컸다.

'smss','csrss','wininit','winlogon','services' | ForEach-Object {
    Get-AuthenticodeSignature "C:\Windows\System32\$_.exe" | Select-Object Path, Status }

일반 권한에서는 이 프로세스들의 Path 가 빈 값으로 나오는데, SYSTEM 계정이거나 보호된 프로세스라서 정상이다. 반대로 일반 권한에서 경로가 그대로 보이는 csrss 가 AppData 나 Temp 아래 있다면 그건 가짜다. 개수도 단서다. smss·wininit·services 는 하나, csrss 는 세션 수만큼, winlogon 은 화면 세션 수만큼이다. 혼자 쓰는 PC 에서 services.exe 가 두 개, wininit 이 세션 1에 있다면 의심할 일이다.

다음 편은 winlogon 이 마지막에 띄운 explorer.exe, Windows 탐색기다. 작업 표시줄까지 함께 맡는 셸이라 멈추면 화면 전체가 굳는다. 다시 시작하는 법과 원인이 되는 셸 확장을 찾는 법을 다룬다.