Windows Processes

Origin text: Blue Team fundamentals Part Two: Windows Processes.


There is a lot of information to be gleaned from Windows processes. The thing with processes is that there are a lot of them, and it can seem massively overwhelming, However with a bit of patience and the aid of a book or three (which I will touch on at the end of this post) you can get really quite far under your own steam.


This obviously requires some form of logging of process trees in a multi host/network scenario, there are a good number of products out there that do this now, especially with buzzword bingo firing on all cylinders, if your endpoint product/agent declares itself ‘next gen’ it should do this. We however, will look at these processes from a single host perspective for the sake of this write-up. The rules and theories will be the same though.

First off we need to arm ourselves with ‘Process Explorer’, which is part of the Windows Sys Internals Suite which can be found at

and when fired up looks a bit like this:

All those lovely processes!

So, lets take a look shall we?


These two are special. Why? Well they are not technically full processes. They are not running a user-mode executable as they are both created by ntoskrnl.exe (NT OS Kernel), which as the name implies means it is running in kernel mode. More information on the difference between user mode and kernel mode can be found here:

Some key features of these two processes are:

  • Neither should have a visible parent process
  • In the case of the idle process it should be operating one thread per CPU as seen here on my quad core machine.
  • The PID value for System is always 4:
  • There should only ever be one instance of System:

What can we look for:

  • If either process has a visible parent ID.
  • If there are more idle threads than CPU’s on the host.
  • If the PID for system is not 4.
  • If you have multiple instances of System.

Session Manager Subsystem/SMSS.EXE

smss.exe is executed during the startup of the OS and is the first user-mode process to be started by the kernel. It starts both kernel and user modes of the Win32 subsystem. This includes win32k.sys (kernel-mode), winsrv.dll (user-mode), and csrss.exe (user-mode). Any other subsystems listed in the following required registry value are also started:

HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems

Required is the value that lists which subsystems should be loaded at boot time.

Windows lists the file specification of the Windows subsystem and we can see it contains %SystemRoot%\system32\csrss.exe

Specifics of this process:

  • It’s Parent will always be System
  • It’s user will always be NT AUTHORITY\SYSTEM
  • Runs from \systemroot\System32\smss.exe
  • all of the above can be seen below:
  • There should only ever be one instance SMSS.EXE running. This is actually very important because it is responsible for launching both WINLOGON.EXE, WININIT.EXE and CSRSS.EXE. Now you might be wondering why this is important? Well, after launching these SMSS.EXE exits and a new instance is started, meaning that when viewing either of these processes, they may have Parent PID (Process ID) attached but the process name should be unknown.
Unknown Parent Process
  • The OS Session is started under Session 0
  • The first user Session is started under session 1

What can we look for:

  • Parent/User is not SYSTEM
  • Seen running from outside of \%systemroot%\system32\
  • Either winlogon, wininit or csrss having a parent process (at all).
  • Unexpected subsystem registry entries.

Flying off on a tangent:

As we touched on Sessions I think it’s worth have a slightly more in depth look at them. If you launch WinObj.exe from sys internals (as admin) and browse to the /Sessions folder you will see something similar to this:

As we already said 0 is the OS session instance and 1 is the first user.

Taking a look at one of the OS session we can see a shared network drive:

Whilst taking a look at user session under WindowStations we see:

So what does this prove? Well preemptively jumping ahead and looking at explorer.exe and it’s associated handlers we can see:

This shows we can view the namespace instance for a specific process.


Windows Logon Process/WINLOGON.EXE

  • Does not have a parent process
  • Runs out of \Windows\System32
  • Can spawn child processes if alternate login devices are used such as card /biometric readers etc
  • Secure Authentication Sequence/SAS (Ctrl+Alt+Delete) is handled by winlogon
  • Loads Userinit from registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon


Specifies the programs that Winlogon runs when a user logs on. By default, Winlogon runs Userinit.exe, which runs logon scripts, reestablishes network connections, and then starts Explorer.exe, the Windows user interface.

  • The registry entry for userinit should be userinit.exe, (The comma is intended). This can be appended with other locations and can be utilised by malware to run things at logon.
  • The shell registry entry in the same location should be Explorer.exe (Windows Explorer). This can also be appended with other values allowing the running of malware at logon.

Registry entries that when modified will load content at logon.
  • As with SMSS.EXE, userinit.exe exits after it has run, meaning anything loaded from registry (explorer.exe, dodgy malwares) will not have a parent process. It also means userinit.exe will not be visible to you in Process Explorer.

What can we look for:

  • Shell and Userinit registry entries with undesirable values.
  • Having a parent process
  • Not running as NT AUTHORITY\SYSTEM
  • Runs out of a location that isn’t \Windows\System32

Explorer.exe / Windows Explorer

As Winlogon runs userinit which spawns explorer, let’s look at the explorer process next.

  • We have already covered the fact that userinit.exe exits after execution meaning no parent process.
  • Again as already covered, the registry entry lives under
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
  • The user will be the logged in account (that which was used to logon via the WINLOGON.EXE process).
  • It runs out of \%Systemroot%\Explorer.exe
Take my word for it, that was my username.
  • Explorer spawns child processes
Child processes spawned from explorer.exe

What can we look for:

  • Not running out of system root.
  • Assuming a genuine naming convention in use, running under context of an unrecognised user.
  • Making any TCP/IP connections.
No TCP/IP connections — This is good.

CSRSS.EXE / Client-Server Run

  • Runs out of \%SystemRoot%\system32\csrss.exe
  • There is an instance loaded for each session, which loads three DLLs; basesrv.dll, winsrv.dll and csrsrv.dll. These dll’s support the creation and deletion of threads and processes (amongst other stuff).
  • It’s a session 0 process

What can we look for:

  • Running outside \system32
  • Running as non SYSTEM user

WININIT.EXE / Windows Initialisation Process

  • Runs from %SystemRoot%\system32\wininit.exe
  • Creates a Window station (Winsta0) and two desktops (Winlogon and Default) for processes to run on in session 0
  • Creates Services.exe
  • Starts Lsass.exe
  • Starts Lsm.exe
  • Always a child of SMSS.EXE (We know this won’t have a Parent process due to smss termination after running)
  • Creates %windir%\temp
  • Runs within session 0

What can we look for:

  • Running outside system32
  • Running as non SYSTEM user
  • Child of an identifiable process.

  • Run from %SystemRoot%\System32\services.exe
  • Child to WININIT.EXE
  • Spawns Multiple services which can be seen in registry location:
  • Run from %SystemRoot%\system32\services.exe
  • The process should spawn many generic svchost.exe which are responsible for running the services.

What can we look for:

  • Running outside \system32
  • Running as non SYSTEM user
  • Child of a process that is not WININIT.EXE

SVCHOST.EXE / Service Hosting Process

  • There will be multiple instances of SVCHOST running as per the following screen grabs:
tasklist.exe /svc on the left, compared to process explorer on the right and you can see the PIDS line up.
all the svchosts
an expanded svchost
  • Runs from %SystemRoot%\System32\svchost.exe
  • Can run as any of the following accounts: NT AUTHORITY\SYSTEM, LOCAL SERVICE, or NETWORK SERVICE
  • Always the child process of services.exe
  • It will always follow the command line convention of “svchost.exe -k [name]”
  • -k [name] values should exist within the following registry location:
Software\Microsoft\Windows NT\CurrentVersion\Svchost
Registry entries
Running under svchost context

What can we look for:

  • Processes not using the -k [name] convention
  • Parent not services.exe
  • Running from outside \system32

LSASS.EXE / Local Security Authority

  • Run from %SystemRoot%\System32\lsass.exe
  • Spawned by WININIT.EXE
  • There should never be more than one LSASS.EXE process.
  • It should never spawn any child processes.
  • Runs within session 0

What can we look for:

  • Not running as SYSTEM.
  • Due to the nature of LSASS it is a high value target for malware and frequently spoofed.
  • lsass not running out of %SystemRoot%\System32\ is highly likely to be malicious.
  • Anything that looks like it has been spawned by lsass is also likely malicious. In most cases this is a malware author using clever font techniques to obfuscate the file; Isass vs lsass for example.

LSM.EXE / Load Session Manager Service

  • Runs from %systemroot%\System32\lsm.exe
  • Parent Process should always be wininit.exe
  • The Local Session Manager manages (← shocking) the state of terminal server sessions on the local machine. It sends requests to Smss through the ALPC port SmSsWinStationApiPort to start new sessions.
  • LSM.EXE should never spawn any child processes
  • Runs within session 0

What can we look for:

  • LSM spawning any child process
  • Running outside system32
  • Not running as SYSTEM
  • Parent process no wininit.exe

Своя маленькая операционная система

А что если хочется написать программку, для которой ничего не надо? Вставляем дискетку в компьютер, загружаемся с нее и …»Hello World»! Можно даже прокричать это приветствие из защищенного режима…
Сказано — сделано. С чего бы начать?.. Набраться знаний, конечно. Для этого очень хорошо полазить в исходниках Linux и Thix. Первая система всем хорошо знакома, вторая менее известна, но не менее полезна.

Подучились? Теперь займемся. Понятно, что первым делом надо написать загрузочный сектор для нашей мини-операционки (а ведь это будет именно мини-операционка!). Поскольку процессор грузится в 16-разрядном режиме, то для создания загрузочного сектора используется ассемблер и линковщик из пакета bin86. Можно, конечно, поискать еще что-нибудь, но оба наших примера используют именно его; и мы тоже пойдем по стопам учителей. Синтаксис этого ассемблера немного странноватый, совмещающий черты, характерные и для Intel и для AT&T, но после пары недель мучений можно привыкнуть.

Загрузочный сектор (boot.S)

Сознательно не буду приводить полных листингов программ. Так станут понятней основные идеи, да и вам будет намного приятней, если все напишете своими руками.

Для начала определимся с основными константами.
START_HEAD = 0 — Головка привода, которою будем использовать.
START_TRACK = 0 — Дорожка, откуда начнем чтение.
START_SECTOR = 2 — Сектор, начиная с которого будем считывать наше ядрышко.
SYSSIZE = 10 — Размер ядра в секторах (каждый сектор содержит 512 байт)
FLOPPY_ID = 0 — Идентификатор привода. 0 — для первого, 1 — для второго
HEADS = 2 — Количество головок привода.
SECTORS = 18 — Количество дорожек на дискете. Для формата 1.44 МБ это количество равно 18.

В процессе загрузки будет происходить следующее. Загрузчик BIOS считает первый сектор дискеты, положит его по адресу 0000:0x7c00 и передаст туда управление. Мы его получим и — для начала — переместим себя пониже по адресу 0000:0x600, перейдем туда и спокойно продолжим работу. Собственно вся наша работа будет состоять из загрузки ядра (сектора 2 — 12 первой дорожки дискеты) по адресу 0x100:0000, переходу в защищенный режим и скачку на первые строки ядра. В связи с этим еще несколько констант:
BOOTSEG = 0x7c00 — Сюда поместит загрузочный сектор BIOS.
INITSEG = 0x600 — Сюда его переместим мы.
SYSSEG = 0x100 — А здесь приятно расположится наше ядро.
DATA_ARB = 0x92 — Определитель сегмента данных для дескриптора
CODE_ARB = 0x9A — Определитель сегмента кода для дескриптора.

Первым делом произведем перемещение самих себя в более приемлемое место.

xor ax, ax
mov ss, ax
mov sp, #BOOTSEG
mov si, sp
mov ds, ax
mov es, ax
mov di, #INITSEG
mov cx, #0x100
jmpi go, #0
;прыжок в новое местоположение загрузочного сектора на метку go
Теперь необходимо настроить как следует сегменты для данных (es, ds) и для стека. Неприятно, конечно, что все приходится делать вручную, но что поделаешь — ведь кроме нас и BIOS в памяти компьютера никого нет.

mov ax, #0xF0
mov ss, ax
mov sp, ax ; Стек разместим как 0xF0:0xF0 = 0xFF0
mov ax, #0x60 ; Сегменты для данных ES и DS зададим в 0x60
mov ds, ax
mov es, ax
Наконец, можно вывести победное приветствие. Пусть мир узнает, что мы смогли загрузиться! Поскольку у нас есть все-таки целый BIOS, воспользуемся готовой функцией 0x13 прерывания 0x10. Можно, конечно, его презреть и написать напрямую в видеопамять, но у нас каждый байт команды на счету, а байт таких всего 512. Потратим их лучше на что-нибудь более полезное.

mov cx,#18
mov bp,#boot_msg
call write_message
Функция write_message выглядит следующим образом
push bx
push ax
push cx
push dx
push cx
mov ah,#0x03 ; прочитаем текущее положение курсора,
; дабы не выводить сообщения где попало.
xor bh,bh
int 0x10
pop cx
mov bx,#0x0007 ; Параметры выводимых символов : видеостраница 0,
; атрибут 7 (серый на черном)
mov ax,#0x1301 ; Выводим строку и сдвигаем курсор.
int 0x10
pop dx
pop cx
pop ax
pop bx
А сообщение так

.byte 13,10
.ascii «Booting data …»
.byte 0
К этому времени на дисплее компьютера появится скромное «Booting data …». Это в принципе не хуже, чем «Hello World», но давайте добьемся чуть большего. Перейдем в защищенный режим и выведем этот «Hello» уже из программы, написанной на C.

Ядро 32-разрядное. Оно будет у нас размещаться отдельно от загрузочного сектора и собираться уже с помощью gcc и gas. Синтаксис ассемблера gas соответствует требованиям AT&T, так что тут все будет попроще. Но для начала нам нужно прочитать ядро. Опять воспользуемся готовой функцией 0x2 прерывания 0x13.

mov ah, #0
mov dl, #FLOPPY_ID
int 0x13 ; проведем реинициализацию дисковода.
jc recalibrate
call read_track ; вызов функции чтения ядра
jnc next_work ; если во время чтения не произошло
; ничего плохого, то работаем дальше

; если чтение произошло неудачно — выводим сообщение об ошибке
mov bp,#error_read_msg
mov cx,7
call write_message
inf1: jmp inf1 ; и уходим в бесконечный цикл.
; Теперь нас спасет только ручная перезагрузка
Сама функция чтения предельно простая: долго и нудно заполняем параметры, а затем одним махом считываем ядро. Сложности начнутся, когда ядро перестанет помещаться в 17 секторах (то есть 8.5КБ); но это пока в будущем, а сейчас вполне достаточно такого молниеносного чтения

push es
push ds
mov di, #SYSSEG ; Определяем
mov es, di ; адрес буфера для данных
xor bx, bx
mov ch, #START_TRACK ;дорожка 0
mov cl, #START_SECTOR ;начиная с сектора 2
mov dl, #FLOPPY_ID
mov dh, #START_HEAD
mov ah, #2
mov al, #SYSSIZE ;считать 10 секторов
int 0x13
pop ds
pop es
Вот и все. Ядро успешно прочитано, и можно вывести еще одно радостное сообщение на экран.

call kill_motor ; останавливаем привод дисковода
mov bp,#load_msg ; выводим сообщение
mov cx,#4
call write_message
Вот содержимое сообщения
.ascii «done»
.byte 0
А вот функция остановки двигателя привода.
push dx
push ax
mov dx,#0x3f2
xor al,al
out dx,al
pop ax
pop dx
На данный момент на экране выведено «Booting data …done» и лампочка привода флоппи-дисков погашена. Все затихли и готовы к смертельному номеру — прыжку в защищенный режим.

Для начала надо включить адресную линию A20. Это в точности означает, что мы будем использовать 32-разрядную адресацию к данным.

mov al, #0xD1 ; команда записи для 8042
out #0x64, al
mov al, #0xDF ; включить A20
out #0x60, al
Выведем предупреждающее сообщение — о том, что переходим в защищенный режим. Пусть все знают, какие мы важные.

mov bp,#loadp_msg
mov cx,#25
call write_message

.byte 13,10
.ascii «Go to protected mode…»
.byte 0
Пока у нас еще жив BIOS, запомним позицию курсора и сохраним ее в известном месте (0000:0x8000 ). Ядро позже заберет все данные и будет их использовать для вывода на экран победного сообщения.

mov ah,#0x03 ; читаем текущую позицию курсора
xor bh,bh
int 0x10
seg cs
mov [0x8000],dx ;сохраняем в специальном тайнике
Теперь внимание, запрещаем прерывания (нечего отвлекаться во время такой работы) и загружаем таблицу дескрипторов

lgdt GDT_DESCRIPTOR ; загружаем описатель таблицы дескрипторов.
У нас таблица дескрипторов состоит из трех описателей: нулевой (всегда должен присутствовать), сегмента кода и сегмента данных .

align 4
.word 0
GDT_DESCRIPTOR: .word 3 * 8 — 1 ; размер таблицы дескрипторов
.long 0x600 + GDT ; местоположение таблицы дескрипторов
.align 2
.long 0, 0 ; Номер 0: пустой дескриптор
.word 0xFFFF, 0 ; Номер 8: дескриптор кода
.byte 0, CODE_ARB, 0xC0, 0
.word 0xFFFF, 0 ; Номер 0x10: дескриптор данных
.byte 0, DATA_ARB, 0xCF, 0
Переход в защищенный режим может происходить минимум двумя способами, но обе ОС, выбранные нами для примера (Linux и Thix) используют для совместимости с 286 процессором команду lmsw. Мы будем действовать тем же способом

mov ax, #1
lmsw ax ; прощай реальный режим.
; Мы теперь находимся в защищенном режиме.
jmpi 0x1000, 8 ; Затяжной прыжок на 32-разрядное ядро.
Вот и вся работа загрузочного сектора – не мало, но и не много. Теперь с ним мы попрощаемся и направимся к ядру.

В конце ассемблерного файла полезно добавить следующую инструкцию.

org 511
end_boot: .byte 0
В результате скомпилированный код будет занимать ровно 512 байт, что очень удобно для подготовки образа загрузочного диска.

Первые вздохи ядра (head.S)

Ядро, к сожалению, опять начнется с ассемблерного кода. Но теперь его будет совсем немного.

Мы собственно зададим правильные значения сегментов для данных (ES, DS, FS, GS). Записав туда значение соответствующего дескриптора данных.

movl $(__KERNEL_DS),%eax
movl %ax,%ds
movl %ax,%es
movl %ax,%fs
movl %ax,%gs
Проверим, нормально ли включилась адресная линия A20 — простым тестом записи. Обнулим для чистоты эксперимента регистр флагов.

xorl %eax,%eax
1: incl %eax
movl %eax,0x000000
cmpl %eax,0x100000
je 1b
pushl $0
Вызовем долгожданную функцию, уже написанную на С.

call SYMBOL_NAME(start_my_kernel)
И больше нам тут делать нечего.

inf: jmp inf
Поговорим на языке высокого уровня (start.c)

Вот теперь мы вернулись к тому, с чего начинали рассказ. Почти вернулись, потому что printf() теперь надо делать вручную. Поскольку готовых прерываний уже нет, то будем использовать прямую запись в видеопамять. Для любопытных — почти весь код этой части, с незначительными изменениями, позаимствован из части ядра Linux, осуществляющей распаковку (/arch/i386/boot/compressed/*). Для сборки вам потребуется дополнительно определить такие макросы как inb(), outb(), inb_p(), outb_p(). Готовые определения проще всего одолжить из любой версии Linux.

Теперь, дабы не путаться со встроенными в glibc функциями, отменим их определение

#undef memcpy
Зададим несколько своих:
static void puts(const char *);
static char *vidmem = (char *)0xb8000; /*адрес видеопамяти*/
static int vidport; /*видеопорт*/
static int lines, cols; /*количество линий и строк на экран*/
static int curr_x,curr_y; /*текущее положение курсора */
И начнем, наконец, писать код на языке высокого уровня… правда, с небольшими ассемблерными вставками.

/* функция перевода курсора в положение (x,y).
* Работа ведется через ввод/вывод в видеопорт
void gotoxy(int x, int y)
int pos;
pos = (x + cols * y) * 2;
outb_p(14, vidport);
outb_p(0xff & (pos >> 9), vidport+1);
outb_p(15, vidport);
outb_p(0xff & (pos >> 1), vidport+1);

/* функция прокручивания экрана. Работает,
* используя прямую запись в видеопамять
static void scroll()
int i;
memcpy ( vidmem, vidmem + cols * 2, ( lines — 1 ) * cols * 2 );
for ( i = ( lines — 1 ) * cols * 2; i < lines * cols * 2; i += 2 ) vidmem[i] = ' '; } /* функция вывода строки на экран */ static void puts(const char *s) { int x,y; char c; x = curr_x; y = curr_y; while ( ( c = *s++ ) != '\0' ) { if ( c == '\n' ) { x = 0; if ( ++y >= lines ) {
} else {
vidmem [ ( x + cols * y ) * 2 ] = c;
if ( ++x >= cols ) {
x = 0;
if ( ++y >= lines ) {
/* функция копирования из одной области
* памяти в другую. Заменитель стандартной функции glibc
void* memcpy(void* __dest, __const void* __src,
unsigned int __n)
int i;
char *d = (char *)__dest, *s = (char *)__src;
for (i=0;i<__n;i++) d[i]="s[i];" }="}" /* функция, издающая долгий и протяжный звук. * Использует только ввод/вывод в порты поэтому * очень полезна для отладки */ make_sound() { __asm__(" movb $0xB6, %al\n\t outb %al, $0x43\n\t movb $0x0D, %al\n\t outb %al, $0x42\n\t movb $0x11, %al\n\t outb %al, $0x42\n\t inb $0x61, %al\n\t orb $3, %al\n\t outb %al, $0x61\n\t "); } /*А вот и основная функция*/ int start_my_kernel() { /*задаются основные параметры */ vidmem = (char *) 0xb8000; vidport = 0x3d4; lines = 25; cols = 80; /* считываются предусмотрительно * сохраненные координаты курсора */ curr_x=*(unsigned char *)(0x8000); curr_y=*(unsigned char *)(0x8001); /*выводится строка*/ puts("done\n"); /*уходим в бесконечный цикл*/ while(1); } Вот и вывели мы этот "Hello World" на экран. Сколько проделано работы, а на экране только две строчки Booting data ...done Go to proteсted mode ...done А что – плохо?! Закричала новая операционная система. Мир с радостью воспринял ее. Кто знает, может быть - это новый Linux ?... Подготовка загрузочного образа (floppy.img) Теперь подготовим загрузочный образ нашей системки.Для начала соберем загрузочный сектор. as86 -0 -a -o boot.o boot.S ld86 -0 -s -o boot.img boot.o Обрежем 32-битный заголовок и получим таким образом чистый двоичный код. dd if=boot.img of=boot.bin bs=32 skip=1 Соберем ядро gcc -traditional -c head.S -o head.o gcc -O2 -DSTDC_HEADERS -c start.c При компоновке НЕ ЗАБУДЬТЕ параметр "-T"! Он указывает, относительно какого смещения вести расчеты; в нашем случае, поскольку ядро грузится по адресy 0x1000, смещение соответствующее: ld -m elf_i386 -Ttext 0x1000 -e startup_32 head.o start.o -o head.img Отделим зерна от плевел, то есть чистый двоичный код от всяческих служебных заголовков и комментариев: objcopy -O binary -R .note -R .comment -S head.img head.bin И соединим воедино загрузочный сектор и ядро cat boot.bin head.bin >floppy.img
Образ готов. Записываем на дискетку (заготовьте несколько для экспериментов, я прикончил три штуки), перезагружаем компьютер и наслаждаемся…

cat floppy.img >/dev/fd0