A few simple notes and tips on how to inspect your Windows system and PC using (mainly) standard tools.

Main Contents:

1. Checking network connections using "netstat" and "tcpview"
2. Hexdump of a file using "debug", or a "hexeditor", or "od"
3. Viewing rootdirectories and personal directories
4. Using the "handle" utility
5. Some notes on checking processes
6. Recommended Tools and Procedures
7. Just a few notes on the Windows Architecture
8. How to list patches and security updates
9. Description of some well-known (older) vulnerabilities in Windows

Appendix A: Where to download nonstandard tools
Appendix B: Listing KB numbers/MSxx Bulletins

1. Checking network connections using "netstat" and "tcpview"

The "netstat" command is a standard Windows utility. It should be present on any Windows system.
The "tcpview" utility comes from the sysinternals suite.

1.1 The netstat utility (standard command)

The "netstat" utility might be an eye-opener at some times. This commandline utility is
available on all Windows versions, although only the latest Windows versions have the most interresting switches.

It's really quite easy to use. It shows all the networkconnections of your machine.
For example, try the following command from the prompt:

C:\> netstat -ab

The -b switch, will show the applictions too, that has a network connection.
This can be very usefull, especially for checking out which applications connects to the internet.

⇒ Use of "netstat -a -b -f" on modern Windows versions:

If you have Vista, Win7, or Win2K8, the -f switch can also be used, which shows the Fully Qualified Domain Names
of the remote sites as well. This too, makes it really interresting:

C:\> netstat -a -b -f

Some example output is shown below:

[ORACLE.EXE] TCP 127.0.0.1:49707 wswin7:1521 ESTABLISHED
[svchost.exe] TCP 192.168.1.71:139 wswin7:0 LISTENING
[iexplore.exe] TCP 192.168.1.71:54018 webmail.versatel.nl:http ESTABLISHED
[iexplore.exe] TCP 192.168.1.71:54024 www6.knmi.nl:http ESTABLISHED
[iexplore.exe] TCP 192.168.1.71:54026 ez-in-f102.1e100.net:http ESTABLISHED
etc..

Notice that you can see your local executables, and to which site (or remote host) they are connected.
If you see any unexpected executable, you can investigate that further.
Also, if you see any unexpected remote site or host, you might want to check that too.

The fifth line in the output above, could have alarmed me. Why would iexplore connect to "ez-in-f102.1e100.net",
and what for site is that anyway???
Then after some investigation, I would have found out that 1e100 is related to Google.
Anyway, this example is clear enough. If you would have seen something like "bad.hackers.com",
something is quite wrong.

It proves that "netstat" is good tool to check your network connections from the commandline.
But "tcpview" is a bit better (see below).

By the way, if you only would want to see connections, say using port 445, you could filter the output like so:

C:\> netstat -a -b -f | find "445"

Note: the -f switch only works on recent Windows versions.


⇒ Use of "netstat -ano" to find the "listening" processes:

If you want to get a list of all the processes on your system, which are listening for incoming connections,
then use netstat with the "-ano" switches, like so:

C:\> netstat -ano

1.2 The tcpview utility (sysinternals)

Nothing is more easier to use than "tcpview". It's a graphical utility and it shows you all networkconnections
which your local processes might have, to which site or host they are connected, or if they are "listening"
for connections, the local and remote ports which are used, and much more.

Just use it from the command prompt like so:

C:\sysinternals> tcpview

The utility shows you the connections in real time, and the output is updated continuously,
An example view is shown below:

Fig 2.


So, you can clearly see which local executable, connects to which remote site, or host, or IP address.
If you see any unexpected site, or local executable, you can investigate that further.
For example, at one of my sessions, I saw that that avgnsx.exe is connected to "a88-221-216-42.deploy.akamaitechnologies.com",
which could strike you as a rather strange site.
Ofcourse, it's easy to "google" on such a site name. You never know what you will learn from that.

It's not only the local executable, or the remote host, which is very usefull to know. In the ouput, you also will see
columns as "Send_Bytes", "Received_Bytes" which is of course very usefull information.

Task:
I want you to do a little homework:
Find out what it means if the Local port is shown as "*", and/or the Remote port is shown as "*".
You do not neccessarily need or use the tcpview utility for this. Just Googling for some sites on the internet,
which explains netstat's output, might give you the needed info.
Actually, this knowledge too, is relevant information for securing your system.

2. Dumping a file and a file header

Why on earth would you be interrested in dumping (or showing) the fileheader of a file?
Good question. Maybe you do not trust a file, and you want to view the signature first (see below),
in order to identify the filetype.

The first 2 (or 4) bytes of the file, usually identifies the type of the file.
So, that means that for example a .jpg file (using ff d8) has another "fingerprint" than for example
a .bmp file (using 42 4D ).

This works more or less "by convention", so standard programs will adhere to it, but it's
not fully garanteed that the fingerprint (the magic number) always is what it should be.

By the way, if you would want to "disguise" a file, a very wrong methode would be by just renaming the file
to something else. For example, if you have the secret drawing 'secret.jpg',
and you rename that file to 'hp255.sys', then you would fool only just a few people.
But if you would change the signature, then that would be a lot more effective.

The above example illustrates the purpose of this section: sometimes there is a need to identify
a file for whatever reason (maybe you do not trust it, and want to figure out the signature first).

Important: as you will see below, it's actually very simple to modify such a signature, so based on the
signature alone, there is certainly no garantee that a file is of a type "it claims to be".

So, how can you view the "true" contents of a file, meaning just viewin all the bytes that makes it up.
First, most commands or tools will show you the hexadecimal representation of data.
So, be prepared to view and get information like "9C 07... etc...".

2.1 Using the "debug" utility:

Most Windows versions still provide for the DOS utility "debug". But it's possible that the most recent
Windows versions, have phased it out. Like for example, Windows7 does not offer the DOS debug.exe anymore.
In any case, this debug utility is really a usable tool for security experts, although alternatives exists.

So, your Windows version (like Win2K3, XP and older) might still contain the debug utility.
If so, you can use the "debug" utility, to dump the contents of (any) file.
Although debug can be used for many purposes, we only need the ability to dump the contents of a file.
It works surprisingly simple. Here is an example. Suppose we want to view the contents of "sunset.jpg".
Then we can do this:

C:\temp> debug sunset.jpg
-d
0B32:0100 FF D8 FF E0 00 10 4A 46-49 46 00 01 02 01 00 48 ......JFIF.....H
0B32:0110 00 48 00 00 FF ED 18 92-50 68 6F 74 6F 73 68 6F .H......Photosho
0B32:0120 70 20 33 2E 30 00 38 42-49 4D 04 04 07 43 61 70 p 3.0.8BIM...Cap
0B32:0130 74 69 6F 6E 00 00 00 10-1C 02 00 00 02 00 02 1C tion............
0B32:0140 02 78 00 04 00 66 92 CF-38 42 49 4D 03 E9 0A 50 .x...f..8BIM...P
0B32:0150 72 69 6E 74 20 49 6E 66-6F 00 00 00 00 78 00 03 rint Info....x..
0B32:0160 00 00 00 48 00 48 00 00-00 00 02 D8 02 28 FF E1 ...H.H.......(..
0B32:0170 FF E2 02 F9 02 46 03 47-05 28 03 FC 00 02 00 00 .....F.G.(......

So, all you need to do is entering the command "debug filename".
Next, a "-" prompt will appear. The "d" command instructs debug to dump the first 128 bytes
of the file. Entering "d" again, will proceed to the next page of bytes. This way you can "walk"
through the file. Entering "quit"will end your debug session.

Do you see the "FF D8" signature in the upperleft corner? That's the magic number for a .jpg file.

Note:

If you are running Windows7, and you do not have the commandline DOS "debug.exe" anymore:
There are plenty of free graphical and non graphical free "hexdump" utilities available.
Most are limited in capabilities, but we only want to get a hexdump of a file, which allmost all
of these tools can do.

One of those tools is xvi32, which should run on all platforms. Please See the next section.

If you want to see some listings of those signatures of many popular filetypes, you might want to check out:

Signatures (1)
Signatures (2)
Signatures (3)

2.2 Using a graphical hex editor:

Many graphical hex editors are around, and some are free too.
They are fairly easy to work with. Like any Windows program, they have a menu system
by which you can easily browse for a file, and open that file to work with.

- One free tool that's really easy to work with is "xvi32". It allows you to read and write (!) to a file.
There is no install procedure. Just download it, unzip it in some directory, and you are ready to go.
You can download it from:

http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm

- Another (small) tool is "hexdump32", and it's limited in capabilities.
You can download it from:

http://hex-dump.qarchive.org/

2.3 Using the unix/linux "od" and "dd" utilities:

If you have a Linux distro on a partition of your machine, you have a lot
of extra power for investigations.

If you do not want that, you can still use a Linux environment from within Windows.
You might consider to install "Cygwin", which is a quite good Linux emulator, with a nice bash shell.
You might want to Google on keywords "Cygwin" or "download Cygwin". This is trusted software.

Once installed, you can startup the Cygwin shell, and for example use the "od" and "dd" utilities.

Getting a hexdump is already as easy as in the following example:

$ od -x sunset.jpg | more


Notes and warnings:

1. On your own system, you can do whatever you like ofcourse.
But if you are a guest somewhere else, and you grab a read/write hexeditor to browse around a bit,
it's garanteed that most people are seriously starting to dislike you.
Indeed, using those tools circumvent all sorts of applicative restrictions, although
the Operating System enforced restrictions, like filesystem permissions, still remain in effect ofcourse.
In particular, if you are indeed a guest at another location, be aware that it's in principle
possible to view data, and even sensitive data. So, suppose you are a sort of consultant visiting a client,
then you MUST inform the client.

2. In using hexeditors with writing capabilities, it's not too hard to accidently,
but definitively, destroy a file.

3. Viewing rootdirectories and personal directories

In the root of your system partion, a number of specific systemfiles are present.
As of Vista and Win2K8, using UAC, it's not likely that malicious files will be placed
in the root of your system- or boot partitions.

⇒ The system partition is that disk partition that contains the boot sector and files such as "NTLDR" (Win2K3, XP),
or the boot loader called "bootmgr" (Vista, Win7, Win2K8) which are needed for the early phases in the bootprocess.

⇒ The boot partion is that disk partition which contains the Windows Operating System directory (like C:\WINDOWS).

Indeed, often the system partition and boot partition are the same (like C:\)

There are a couple of important places you can check for unexpected files. For example, if your home directory is
is "c:\users\albert", and you see a ".dll" file which is unexpected, or some executable called for example "smss.exe",
then you might have discovered a piece if malware.

Also, some bootfiles (like bootmgr for Win7) are supposed to have only the "R" attribute (not referring to acl's).
There is a good reason for that. If they would have "RW", then some malicious code could (in principle) alter them.
Thats why a simple check on attributes on bootfiles and related startup files, is a good check too.

The following are suggestions of locations you might want to check for hidden files, or files which should only have "R",
or files which are recently placed in these locations.

- the root of the system partition and bootpartition,
- the root of (all of the) the user home directories and all subdirectories,
- the %systemroot% directory (like c:\windows) and all subdirectories.

The root of the system partition and the %systemroot% directory, are usually well protected by the operating system.
But many people tend to work on their private systems with Administrative authority, which makes it more easy
for illegal writes in these places.

The following is certainly not rocket science: these are just a few standard checks.

3.1 Using attrib for viewing system- and boot partitions:

Here it is:

- Determine what your system- and bootpartitions are. Suppose we only have C:\
- Open a command prompt (cmd).
- Goto the root of the system partition
- Enter the command "attrib"

- for example, On a Win7 system, we should see this list:

C:\> attrib

A SHR C:\bootmgr
A SHR C:\BOOTSECT.BAK
A SH C:\dell.sdr
A SH I C:\hiberfil.sys
A SH C:\pagefile.sys

- and, for example, On a Win2K3 system, we should see something similar to this list:

C:\> attrib

A C:\AUTOEXEC.BAT
A C:\CONFIG.SYS
A SH C:\BOOT.BAK
A SHR C:\boot.ini
A SHR C:\IO.SYS
A SHR C:\MSDOS.SYS
A SHR C:\NTDETECT.COM
A SHR C:\ntldr
A SH C:\pagefile.sys

The attrib command just gives a list of files in the root, with their "attributes", like "S" (system),
"H" (hidden), "R" (read-only).
In my case "bootmgr" and "BOOTSECT" have the right attributes, S and H, and they need to be read-only too (R).
There is no reason why the R attribute is missing, which would make them writeable (which should never happen).
The "pagefile.sys" and "hiberfil.sys" have S and H too, but they indeed must be writable, so the R is missing,
which is correct.

⇒ It's really strange if a systemfile like for example "bootmgr" would have the R attribute missing.
If you see that, it's worth investigation.

⇒ There should not be much more other files in the root. Ofcourse, many people accidently
save documents in the root, but those usually are fairly easy to identify.
But if the system is a multi-boot system, other files could be present as well.

If you see a file with "$" or "?", then it could be some tempfile of some application.
But keep in mind that normal user processes should never be able to write in the root.
So, something is wrong anyway on your system, security wise.
In general: it's wise to get suspicious if you see files that does not belong in the root.

In the above output, on my system, I also see a file called "dell.sdr", which I think
really should not be there. Taking a hex dump (which will not "activate" code in that file),
I only see some ascii code, and indeed it got something to do with Dell support.

It's also wise to repeat the process for your personal user directories.

In a later section, we will talk more on tracking the origin of "strange" files in the root.
For now: scan your system with an up to date AV tool.

3.2 Using "dir" and "findstr" and some basics of Powershell (standard commands):

It sounds amazing, but even using the most simple tools can help.
Suppose you are curious to the latest files that have "arrived" (possibly wihout you knowing) on your disk(s).
You might even try just the (often underrated) "dir" command, like in the following examples.
Here, we have interest in just a listing of the most recent files.

C:\directoryofinterest> dir /o-d

C:\directoryofinterest> dir /o-d /s > list.txt

Everybody knows of the "dir" command, but using it with the "/o-d" parameters is not so well known.
You need to expriment a bit with such commands. On more recent Windows versions, it's best to start a prompt
with elevated credentials (rightclick: Run as Administrator)

Using Powershell gives us many more options. It's not hard to learn some basic commands of Powershell.
Here are a few examples. The following should give you a list of the 5 most recent files in some directory:

C:\WINDOWS> powershell

PS C:\WINDOWS> dir | sort -prop LastWriteTime | select -last 5

Directory: Microsoft.PowerShell.Core\FileSystem::C:\WINDOWS

Mode LastWriteTime Name
----- ------------- ----
-a--- 10/1/2011 3:04 iis6.log
-a--- 10/1/2011 3:05 windowsUpdate.log
d---- 10/1/2011 7:07 Temp
d---- 10/1/2011 1:47 Prefetch
-a--- 10/7/2099 10:36 PMKB968389.log

Or if you want to use it recursivly (the dir /s equivalent) to search all subdirs too:

PS C:\SOME_DIRECTORY> dir -r | sort -prop LastWriteTime | select -last 10

The points of this chapter are:

- If you see the wrong attributes of bootfiles in the system/boot partition(s): that's strange.
- If you see unidentified files in the system/boot partition(s): that's strange.
- If you find unexpected recent files in the root, or in some subdir of home directories: that's strange.
Especially if you have found .dll or exe files, then something might be wrong.

One trick that some hackers apply is to have a reference to such a file in the Registry, so that
it will "autostart" at boottime. See section 5.7 for more information.

Actually, we should be able to boot from a bootable DVD, and start investigations and scans from there.
That will be dealt with in a later section: how to create a bootable DVD.

4. Using the "handle" utility:

Here we will show you the main usage of the "handle" utility from the "sysinternals suite".

A "filehandle" is a number, and it's a reference to a certain file.
Suppose you create some program, and you declare this:

$var="c:/data/turnover.txt";

Then at runtime, your program get's a handle (a way to access) to that specific file.

The "handle" utility is a prompt tool, so open a cmd window (with elevated privileges
if you run a Windows version above Win2K3/XP).
It's very easy to use. You can view just all handles in your system, or you can zoom in
into a set of processes, like the set that matches a choosen partial name.
You are also able to close a handle, if a file needs to be "freed", but then you better know
exactly what you are doing.

In this section, I am only interrested in viewing handles. Here is how you can use it:

C:\TEMP> handle > handles.txt

Here I redirected the output into a text file, which I can study at ease.
The handle utility can use a number of switches (like -a), but first I advise you to use the default
command like shown above. Even still, there is a lot of output. A fragment is shown below:

----------------------------
avgchsva.exe pid: 392 NT AUTHORITY\SYSTEM
4: File (RW-) C:\PROGRA~2\AVG\AVG10
170: File (---) U:
280: File (---) F:
2C4: File (---) E:
2FC: File (R-D) C:\ProgramData\AVG10\Chjw\36a2d424a2d3e681.dat
340: File (R-D) C:\ProgramData\AVG10\Chjw\ac7c4ec27c4e86d4.dat
(more records, but omitted)
----------------------------
h.exe
26C: File (RW-) C:\users\albert\h.dat
----------------------------
BingApp.exe pid: 2008 wswin7\root
C: File (RW-) C:\Windows
14: File (RW-) C:\Windows\SysWOW64
130: File (R--) C:\Windows\registration\R000000000002.clb
(more records, but omitted)
----------------------------
..
..
etc.. Much more output omitted.

Remember, if you run "handle", you get a sort of photograph of your system at a particular moment.

It's not easy to browse through such a long list.
However it is in principle possible that you see some process having a handle
to for example a system file, which you did not expect at all.
In the above output, I see "h.exe" having a handle to a file in my home directory.
That could have been really remarkable! I could have been very surprised.
But I reckognize that program as one of my own utilities.

But if it wasn't one of my own tools, it would have been a good example on how you should screen
the output for strange or unexpected events.

I think it proves how usefull this tool is.

Remark: handle will not show you RPC's and other interprocess mechanisms.

5. Some notes on checking processes.

In this chapter, we first review some results that the standard utilities (which are likely to be present
on your system) can show us, and we will take a look at a few tools from the "sysinternals suite."

Although we will find some interesting material on processes, it's not really very likely that we will "score" with
using solely inspecting memory using the standard tools of Windows.
However, we might (in principle at least) be able to identify (obvious) fraudulous code like trojans etc..,
if we can identify unexpected startup directories, and these then can be identified by checking process parameters.

5.1 Using the "tasklist" command (standard command):

The "tasklist" command, immediately shows you the image names of all running processes on your system, as well
as the pid (process id) and other data like the memory consumption.

C:\> tasklist

smss.exe  796 Console   420 K
csrss.exe   844 Console   4,140 K
winlogon.exe   868 Console   3,652 K
services.exe   916 Console   3,564 K
lsass.exe   928 Console   1,604 K
svchost.exe   1096 Console   5,152 K
svchost.exe   1164 Console   4,532 K
svchost.exe   1308 Console   33,788 K
etc..

Unless you work on a terminal Server, the standard Windows processes (like smss.exe, lsass.exe etc..),
should be listed once.
So, if you happen to see such a named standard Windows process multiple times, then it is possible that we found
a fraud of some sort. In this case, it's really worth while to know about the common facilities in Windows,
and what their functions are (like lsass.exe, smss.exe, csrss.exe, services.exe etc..)

Ofcourse, if you have started some user applcation "n times", it's no wonder that you see it "n times" in the tasklist.
There are exceptions as well. Some (unnamed) processes are correctly repeated, like the "svchost" processes, which
of which you will probably see multiple instances running on a typical Windows machine.

These processes are, in normal circumstances, allright, because "Svchost" is used to run services
which are coded in (for example) .dll libraries.

If we want to view what svchost is actually running, we can use this command:

C:\> tasklist /svc | find "svchost"

This should return a list of services which are "hosted" by the svchost.exe processes.
For example, you might see output resembling this:

C:\temp> tasklist /svc | find "svchost"

svchost.exe 656 DcomLaunch
svchost.exe 712 RpcSs
svchost.exe 776 Dhcp, Dnscache
svchost.exe 812 Alerter, LmHosts, W32Time
svchost.exe 832 AeLookupSvc, AudioSrv, Browser, CryptSvc
svchost.exe 1192 ERSvc
svchost.exe 1448 RemoteRegistry
svchost.exe 2124 TermService
svchost.exe 2804 TapiSrv

The services names in the output of the command above, should also be listed in the services records
that can be found in the Registry in the following location:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Svchost

If there is a mismatch, that is, the output of the command is not also listed in the Registry,
then here is point for further investigation. We might use the wmic command for that purpose.
Let's go to the wmic command, and how it might help us.

5.2 Using the "wmic" command (standard command):

One further point of interrest may be, that you get "the directory" from which a process is started. If you see some
"unlogical" directory, then something might be wrong. Ofcourse, it's not always easy to reckognize what a proper directory
should be, but if one "obviously stands out", then you might get suspicious.
For example, you might be alarmed if you see some process that was started from some subdirectory of your homedirectory.
The point is, that usually processes do not start from (a subdir of) your home directory, unless you develop code
and know about it.
You can get such a list using a "wmic" command:

C:\TEMP> wmic process get caption, commandline > list.txt

Here, I redirected the output of the wmic command to a textfile (list.txt), so that we can inspect that file
at our leisure.

Also, it's instructive to get a list of processes with their pid's, parentpid, ExecutionPath, caption, and Name:

C:\TEMP> wmic process get caption, Description, ProcessId, ParentProcessId, SessionID,ExecutablePath > list.txt

You can browse through that textfile a bit. Maybe you see some interesting stuff in the paths of the executable,
or the link between ParentProcessID and ProcessID etc..
As said before, especially the startdirectory of some process might be a good pointer.
However, using solely standard commands, will always result in a bit of a puzzle indeed.

5.3 Viewing "scheduled tasks" (using standard commands):

On many systems, processes will be launched (at scheduled times) from the Windows scheduler.
Using Control Panel, you can go to a graphical interface to view scheduled tasks on the Windows Operating system.
Always check the scheduled tasks too.
From a command prompt, you can also use the following commands:

C:\temp> schtasks

C:\temp> at

Inspect the output closely. Especially on Win2K8 Servers, a lot of systemtasks might already be present,
which makes browsing the list not easy. But it should be possible to indentify tasks which should not be there.

5.4 Using "regedit" to find autostart (usermode) processes (standard tool):

There are a few places in the registry, which are associated with automatically starting software,
(not referring to "services") or are in an other way quite "sensitive".
You can either start regedit and look at those keys manually, or you can export the keys to txt files,
and inspect them at leisure. Here is a limited list of some important keys:

C:\TEMP>regedit.exe /e c:\temp\sys_run.reg HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

C:\TEMP>regedit.exe /e c:\temp\sys_runonce.reg HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

C:\TEMP>regedit.exe /e c:\temp\usr_run.reg HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

C:\TEMP>regedit.exe /e c:\temp\usr_runonce.reg HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

C:\TEMP>regedit.exe /e c:\temp\svchost.reg HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Svchost

C:\TEMP>regedit.exe /e c:\temp\sec_center.reg HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Security Center

Also export the key that lists possible dll's that might hook on user32:

C:\TEMP>regedit.exe /e c:\temp\app_init.reg HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

Also you want to know what values are stored in the "BootExecute" record of the Session Manager:

C:\TEMP>regedit.exe /e c:\temp\bootexec.reg HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Control\Session Manager

The "/e" switch means that you want to do an export of a certain key.

5.5 Using "autoruns" to find autostart (usermode) processes (using sysinternals):

What we have seen in section 5.4 (finding processes that autostart from the Registry), can be done better, and with much more ease, using the "autoruns" utility from the "sysinternals suite".
It will show you all programs that have an autostart implemented, either from the Registry, or otherwise.

This tool is easy to use. From the prompt, just navigate to the directory where the sysinternal tools are stored,
and enter the "autoruns" command, to call that utility.

C:\sysinternals> autoruns


Not only will it provide a list of all autostarted processes, but also the "scheduled tasks", and much more,
from one neat graphical utility.


The following is not considered by everybody as a vunerability, but it's more like some other "facility"
to automatically launch code.
But at the same time, it still is a subject that's worth to consider or investigate.

Above, we have seen some examples of "autostart" facilities of Windows: Here, some Registry locations were shown,
which might be of interest.

But there is some more to consider. I am afraid that the following will strike you as extremely trivial, but I have
seen quite some malware that simply uses the "Startup" directory within your Home directory, as a way to activate code.

Anything that's executable (scripts, executables etc..) in "Startup", will be lanched after logon.
So, this directory must get your attention.

Usually, it contains some regular stuff, like modules from Office, WinZip and the like.
Anything you do not reckognize as a official piece of code, should be investigated.
One thing is for sure: it can't have names like we have seen in Chapter 7, like lsass.exe and the like.
You can always move those modules to a "quarantine" location.
But if you just do an AV scan, it's very likely that the AV utility will destroy or quarantine them.

Alongside of manually scanning locations, also the "autoruns" uitily from the sysinternals suite is very usefull
for showing "autostart" Registry locations, as well as what lives in the "Startup" directories.

Note: on some systems, "Startup" is called "Autostart".

Be aware that actually (at least) two "Startup" locations exist:

- one in your "personal" directory,
- and one for "All Users".

⇒ For modern systems, like Win7, Win2K8, you might inspect:

- Your personal startup folder:

%systemdrive%\users\%username%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

-For all users, you will find the startup folder in:

%systemdrive%\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup


⇒ For systems like XP, Win2K3:

You might want to inspect the "personal" and "All Users" Startup folders under "%systemdrive%\Documents and Settings".

5.6 Retrieving a list of services, and altering the state of services (using standard commands):

In section 5.4 we have seen that processes can be set to autostart from the Registry (for example via the "Run" key).

But in one of the last phases of the Windows bootprocess, the socalled "services" are started.
Here, a deeper level of control is implemented in the Registry. The "services" are processes too, but they are started by several components in the booting phase.
Starting them this way, during boot, ensures that they run in specific environments.
This "configuration information" of those environments, is all stored in the Registry.

Here are the main environmental information for services, which ensures tight control:

• If you install a service, often you must choose a security context for the service to be started under
  (because these services are typically not started by a user).
  So, we can determine under which credentials they will run (like the local "system", or some Domain account etc..)


• Windows setup, or the installation program of a service, determines which "dependencies" exists, like for example
  which service(s) should be running first, before this particular service should start.


• The "startup type" is determined, like "disabled", "manual", "automatic".

Furhermore, the services are started independend of which user logs on to the system, and indeed an interactive logon
is not even needed for services with a startup type of automatic (and in some cases for "manual" too,
if another service starts it.

You may compare them with, for example, the socalled "daemons" (background processes) in Unix.

Using Control Panel, or the "services.msc" facility, you can go to graphical utilities that shows you all
installed services, and their properties (like the account under which they run, the dependencies, the startup type etc..)

Sometimes it can be usefull to get a list of what services are running on your system, or which services are
installed on your system, because not all services are probably running right now (e.g.: startup type manual)


The follwing commands will get you several listings of services:

1. Showing all running services ("ServiceDisplayName"), using the "net" command:

C:\TEMP> net start

2. The same as (1) but this time the output is redirected to a text file:

C:\TEMP> net start > listing.txt

3. Using the SC command to get a list of all services (running or not running)

C:\TEMP> SC QUERY state= all |findstr "DISPLAY_NAME STATE" > listing.txt

4: Get the executable from the ServiceDisplayName, as is registered in the corresponding Registry key:

C:\TEMP> sc GetKeyName "ServiceDisplayName"

5: Get the all config info of the ServiceDisplayName (including the binary, and logonaccount):

C:\TEMP> sc qc "ServiceDisplayName"

6: Show all depended services of a service:

C:\TEMP>sc EnumDepend "ServiceDisplayName"

The follwing commands will let you stop or start services:

6. Stop a service, using the "net" command:

C:\TEMP> net stop "ServiceDisplayName"

7. Start a service, using the "net" command:

C:\TEMP> net start "ServiceDisplayName"

6. Stop a service, using the "SC" command:

C:\TEMP> SC stop "ServiceDisplayName"

7. Start a service, using the "SC" command:

C:\TEMP> SC start "ServiceDisplayName"

Although the above commands is just a limited list, it enables you to quickly get important
services related information. Especially for quickly getting a concise listing, (3) is quite usefull.

What in Windows slang is called "services", are actually:
- user mode processes (like the Exchange services, the SQL Server service, all of the standard services)
- drivers

All services and their properties are listed in the Registry under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Some services (drivers) are more or less "ordered" in service groups, which expresses their dependencies.
The following subkey determines the order in which Service Groups are loaded:

HKEY_LOCAL_MACHINE\CurrentControlSet\Control\ServiceGroupOrder

The driver "services" which are running on your system, can be viewed using the following command:

C:\TEMP> driverquery

Note:

You can also use the "psservice.exe" tool from the sysinternals suite to get information, or to alter the state.

5.7 Listing DLL versions and usage (using sysinternals):

We know that a dll file is compiled code, usually consisting of "callable" functions, which can be used by
other components. See chapter 7 for more information on executables like .exe and dll's.

Here, in this section, we might be interested in:

• What dll's is a certain process (pid, or name) currently using
• Which unsigned dll's are on my system
• Which dll's are not loaded at their base address

We should not make a too big deal of this all. Sure, it's interresting to know what dll's a process is using,
and it's also good to know which dll's are not signed.
But the information can only be part of a larger picture.

An "Unsigned dll" sounds more worse than it actually is (although signed stuff sounds, and is, better).
In modern development environments, you can create strongly named assemblies (signed) which in principle
can be validated against the public key of the issuer, to prevent you from using code that has been tampered with.
So, indeed, it's "better". But do NOT be alarmed if your system has a number of unsigned dll's.

Since we are using the "sysinternals suite", we can use the "listdlls" utility, to show us this sort of information.


- Listing the dll's a process is using (listdlls pid):

This is quite easy. Use the listdlls utility, with the pid or processname as a parameter.
For example, startup any executable (like notepad or anything else).
Using the tasklist command, you can always find the pid (process id) of that process.
Suppose that in this example, the process of interest uses a pid of 2824:

C:\sysinternals> listdlls 2824

notepad.exe pid: 2824
Command line: notepad

Base Size Path
0x01000000 0x14000 notepad.exe
0x7c800000 0x108000 kernel32.dll
0x76350000 0x4a000 comdlg32.dll
0x77da0000 0xaa000 ADVAPI32.dll
0x77e50000 0x93000 RPCRT4.dll
0x77fc0000 0x11000 Secur32.dll
0x773a0000 0x103000 COMCTL32.dll
0x77be0000 0x58000 msvcrt.dll
0x77ef0000 0x49000 GDI32.dll
..
etc.. (shortened list)


- Listing unsigned dll's:

Using this information "as is", is really pretty useless. You might find a large number of unsigned components,
and you should not be bothered too much. So what's the point in using it? It can be part of a larger investigation,
so, in that case the info could be of use.
Although the sysinternals suite is truly excellent, this particular utility might also produce incorrect results.
That is, I have used it for components which were definitely signed, although listdlls report it as unsigned.
Again: don't use the info "as is" (as a standalone result).

C:\TEMP> listdlls -u > listing.txt


It seems that different versions of the utility, uses somewhat different parameters, and the output might vary somewhat too.
On my system, the following command produces a list of all processes and what dll's they use:

C:\TEMP> listdlls -r > listing.txt

5.8 Using "procmon" to watch processes (using sysinternals):

The "procmon", or "process monitor", is a utility from the "sysinternals suite".
It's very easy to use. You simply need to start it, either in the usual way using the graphical GUI,
or enter "procmon" from the dos promt at the directory where this utility is stored.

Immediately, your screen gets filled with process events. Study the columns that you see in the output.
It's very important to know, that procmon is sampling here. So as time progresses, the output
increases, and thats why you see the same listed process so many times.

It's best to create a filter. The most simple filter, is to Exclude "procmon" itself.
This is so, because procmon heavily interacts with Windows events subsystem.
So, try to find the "filter" option, and exclude procmon as is shown in the figure below.

Fig 3.


Now that we have excluded procmon itself, before we take a look at the output it produces,
there is another important option to set. You can determine which colums you want to see
in the output. Just browse the menusystem until you find how you can set the columns.
This can be important, because regular software will have all sorts of attributes set, like
"Company Name", "Version" etc.. Malicious software often do not have that kind of information.
Also, we are very interrested in the "Image Path" (where it was launched from), so check
that item too.

Fig 4.


Now let's take a look at the output. Let procmon sample, for say 20 seconds. You can take a
longer time, but even after 20 seconds you probably have many thousends events.

Fig 5.


In fig. 5, you can see a small sample of output. Note the "Image Path" column, which clearly
identifies where the process was started from. If you see unexpected directories, you might have
found suspicious code. In this example (see fig. 5), I see some sort of syschk process, started from my home dir.
This is very remarkable, because first that program has a friendly name like "syschk" as if
it is some sort of checking program that "does good work". I don't trust that.
Secondly, it was launced from my home dir which is very suspicious.
Thirdly, it does not have valid attributes like "Company Name", "version" etc..

6. Recommended Tools, Procedures

What I recommend in assembling a minimum toolset, and a minimum of operational knowledge, procedures etc.., is:

• Be carefull with your original DVD's of your Operating Systems. Store them at a safe place,
  in case you need them again. It sounds trivial, and it actually is.


• For all your Windows versions (like Vista, Win2k3, Win2k8 etc..), make a bootable DVD with a selection
  of trusted tools. When needed, you can start investigating and scanning from a clean boot.


• Make sure you have good backup/recovery procedures. Also, make sure you do not only have recent backups,
  but older data backups as well, for example, in the form of week- and month- and year archives.


• If you have a laptop for investigation purposes, consider having a multi-boot environment, with
  Windows- and a Linux partition (not VM's). Linux has first of all a shell and commands which is hard to beat
  (like dd, awk, sed etc..) and it is extra powerfull in network-, debugging- and scripting commands.


• If you are already aquinted with a good scripting environment, that would be really great. If not, make sure
  you get a good working knowledge of Perl, or Powershell, or another environment with similar capabilities.


• Make sure you have a good hexdump utility, with which you can view the "real" contents of a file.
  As an alternative, some full *commander* packages are available with file management capabilities and hexdump options.


• Make sure you know how to work with some network analyser/sniffer. It also means that you need a minimum of knowledge
  of network protocols as well (e.g. OSI layers, the working of: TCPIP, switches, mac, routers, VLAN's, 802.x etc..)


• Make sure you you have a good idea about the top 5 (or so) AV utilities and their capabilities.


• On Windows: make sure you understand NTFS permissions, Share permissions, the various groups that can
  be found in a Domain and in Active Directory, and how permissions are applied to groups.


• On Windows: make sure that you know how to work with the standard tools (like netstat, schtasks, at,
  tasklist, wmic, regedit, sc, net commands etc..) See chapter 4 for a short intro.


• On Windows: make sure you understand the bootprocess with all it's phases.


• On Windows: make sure you can work with all repair options, when you boot from install media.


• On Windows: make sure you generally understand processes as hal, ntoskrnl, csrss, smss, win32 api, ntdll,
  the standard services and the commonly found application services etc...


• On Windows: make sure you have a general understanding of rpc, dcom, ipc mechanisms, semaphores, handles.
  
• On Windows: download the Sysinternals suite, and get aquinted with the most relevant tools.


• On Windows: better also download and test the Moonsols tools, or equivalent toolset.


• On Windows: make sure that you can create and analyze a memory dump.

This is only a simple and humble note for Windows. We have seen nothing yet! We know that we have people who
are specialized in for example unix security, database security, network security, middleware security etc..
Not to mention all the social, psychological, and even economical insights of computer criminology.

7. A few "quick notes" on the Windows Architecture

7.1 Overall general Architecture Windows:

I was never too happy with the public available Windows architecture figures, so I tried to create one myself.
Indeed it's not so very detailed, but the main processes can be clearly identified, and "where they are"
in this Operating System.
I am not sure the discussion below will "help" in any way, but somehow I think that basic knowledge
of the common internal processes, is relevant. So, why not? If you are not interested, you might just skip it.
But..., please realize that the best protection probably comes from understanding the OS
and it's processes. But the discussion below will be extremely short.

Fig 6.

7.2 More on processes and mechanisms:

7.2.1 A few notes on "applications":

When discussing applications on a Windows system, there are few "mainstreams" to consider:

⇒ The "oldfashioned" user apps, which "deal" with the well-known WinApi. So, suppose somebody creates a VB6 app,
then it directly uses comdlg32, user32 and a series of other API dll's, all belonging to the csrss subsystem.
CSRSS is short for Client Server SubSystem.
These apps are often called "unmanaged" code.

⇒ The "newer" Dot Net apps, which uses a well defined series of class libaries.
The apps live/run in the CLR susbsystem.
They have a selfdescribing "manifest" which (should) clearly define what this application needs.
So, there is (generally) no need for all sorts of wild dll's and unclear Registry entries.
As it was presented quite some time ago, you can xcopy the app from a media to your system, and it
can be run without difficulties (this is somewhat "relaxed" nowadays).
These apps are often called "managed" code.
Indeed, generally security should be enhanced using fully managed code.

⇒ Native NT apps, which might (but not always) use the (true) systemcall interface directly (ntdll.dll),
like glibc* on linux. The normal Regular apps (like Excel etc..) are not native.
Some Windows components themselves are called Native NT apps, because they need to activate and perform
work during the bootphase, before the WinApi is up an running.

For example, the SMSS subsystem is up quite early in the bootphase (before the WinApi)
and it checks "HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute
to find modules which should run before all of the "rest" of the usermode systems are up.

In principle, one can create a Native app, by using special compile options, tricks with makedef files etc..
but it is just not fully documented. So, this is for Microsoft, and maybe intimate partners.

⇒ true drivers or kernel mode drivers.
Since the NT family is not exactly "open software", a couple of "kits" are available to write those drivers.

⇒ User mode "background processes", which are the "services" as discussed in section 5.6.
An example is the "mssqlserver" service, which is the database engine of Microsoft.
If you run "services.msc" you can view all of your services (see 5.6).


7.2.2 The Win Api - CSRSS.exe executable + series of dll's:

On a 64 bit system, ordinary applications will use the 64 bit WinApi, or csrss subsystem. The "bulk" actually
is formed by user32.dll, kernel32.dll, comctl32.dll, advapi32.dll and a few other dll's
Those modules export functions that the regular applications can call, for various actions.
If you use a 32bit app on a 64 bit system, then those will use a mini csrss system, called SysWOW64, which
contain the 32 bit versions of the forementioned dll's.
When using 32 bit apps, on Windows 64 bit, a rather elaborate mechanism is used to make sure the 32 bit apps are
redirected to the SysWOW64 api.
(note: it's always best to use 64 apps on 64 bit Windows, for performance reasons.)

Suppose you have a 32 bit Win2K3 system, then you have just have a single 32 bit WinApi, which is also called
the "csrss" subsystem.

Let's illustrate this. Suppose I use notepad (or any other app), and suppose I want to know on what dll's it relies on.
There are some tools which can show us, for example, the "Dependency Walker" which is often used by developer,
will tell us. See Appendix B on how to get it.

For us, it's very easy to use. Ofcourse, there are so many options in this tool, but we are only interested
in on what modules it depends on. So, just open the "File" menu, and search for notepad (or other .exe, .dll)
In figure 7, you see what notepad needs to function, and in figure 8, I just loaded another dll to explore
what dependencies that dll has.


Fig 7. Dependency Walker used on notepad (on win7).



Fig 8. Dependency Walker used on some arbitrary dll (on win7).



7.2.3 LSASS.exe - Local Security Authority SubSystem:

Lsass.exe is a Core Component for the Windows Security system. It is, among other functions,
involved in "User authentication".
For an interactive logon, it works together with "winlogin" and GINA (XP, Win2K3),
or "winlogon" and the socalled "Credential Providers".

- Win2K3 / XP:
As you can see from figure 6, msgina/winlogon is the "getty" in Windows (lower than Vista),
or the "Graphical Identification and Authentication DLL", It is responsible for the Ctrl-Alt-Del
dialogbox and handling. It works in the context of the "winlogon" service.
a GINA uses the Winlogon mechanism for Ctrl-Alt-Del (and possibly "smart card" SAS events).

One potential problem however, was that the system itself, runs in Session0, and the winlogon/gina
subsystem becomes an integral part of that session.

- Vista and higher:
As of Vista, it actually has changed a bit. Socalled "credential Providers", are used by winlogon
which in effect "decouples" the interactive logon (and subseqential processes) from the system session.

Ultimately, LSASS is responsible for authenticating a user. It uses security packages/providers for that purpose.
The "Security Support Provider Interface (SSPI)" functions as a common interface, to several
Security Support Providers (SSPs), like "NTLM" and "Kerberos".
Winlogon passes the user credentials to LSASS, which then determines which account database is to be used.
That could be the local SAM (local accounts database), or an Active Directory logon.


7.2.4 SMSS.exe - Session Manager SubSystem:

We have already seen some features of smss. It's the first usermode process that get's started.
The SMSS subsystem is thus "up" quite early in the bootphase (before the WinApi)
and it checks "HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute
to find modules which should run before all of the "rest" of the usermode systems are up, for example "autochk",
which will mount (drivers are already by long loaded) the drives and checks them if needed.
Then, it's main task is to start other subsystems, most notably the Win Api (csrss) and winlogon.


7.2.5 Native interface ntdll.dll:

It's the upper layer over the kernel: ntoskrnl. Furthermore, as it is the interface between usermode subsystems,
and the kernel processes, it also truly implements the "base APIs" exported by Kernel32.dll".
It's indeed true that all dll's of the WinApi (csrss), rely on the base services of ntdll.

Programs that interact with the user, like showing dialogboxes and controls, are either .Net or WinApi
programs. If a program solely uses NTDLL, then it has no common user interactions with dialogboxes etc...
Almost no regular applications uses NTDLL directly. They interface with kernel32, which then itself interfaces
with ntdll.dll.

The main purpose of the ntdll.dll component then is, to provide the WinApi kernel32.dll library,
with a large set of utility functions. The function set exported by this DLL can be divided into two basic categories:

- Runtime functions executed entirely in user-mode. This set includes parts of the standard C runtime library.
- Kernel function wrappers that perform a switch from user-mode to kernel-mode and back.

In the figure below, I used Dependency Walker on an executable thats part of an AV suite.
Do you notice that it also uses NTDLL directly?
Actually this fact is not so very special. It's just an example of an app that exhibits this behaviour.

Fig 9. Using Dependency Walker on an executable of an Anti-Virus suite.



7.2.6 Stacks and Heaps:

- Theoretically, the "stack" is the memory set aside as sort of scratch space (variables) for a thread of execution.
Each thread created, gets attached to it's own stack. When a function is called, a block can be used on
top of the stack. It uses a simple LIFO algolrithm to keep track of blocks.
- "Heap" is the usual name for the "free space", the memory space where dynamic objects are allocated.
The heap is used by a programmer to reserve for allocations. An object in a heap will be removed, when you
have programmed to do so. An object on the stack is destroyed automatically when its scope ends.
It's much harder to keep track of used/unused blocks in the heap, compared to the simplicity of stacks.

Typically, a process has one (or a few heaps), while each thread has its own stack.

when you use new or malloc() for a new object, the memory is normally allocated from the heap.
When you allocate a pointer or variable within a function, it goes on the stack.
Normally, When a new object is declared this way, you will be allocating memory from the heap
but you need a pointer (sort of variable) to store the location.

Stacks are for the small "things": local variables for functions. Heaps is for the larger "things":
objects, filepages and that kind of objects.
The heap is therefore associated with the process.

7.2.7 Quick note on: Program Load:

⇒ WinApi program:

When an executable is started, a new process is created. Each process gets a virtual address space.
In this address space various things are loaded or created by Windows, before the executable can run.
Among which are:
- All Windows needed libraries (kernel32.dll, etc...)
- The executable itself
- All the libraries that the executable imports
- The Process Environment Block (PEB), which stores information about the process
- A Thread Environment Block (TEB) for the main thread
- A stack for the main thread
- One or more heaps (often one, sometimes two)
- a stack for each new thread.

Viewed from a "file format" perspective, the executable file (.exe, .dll., .sys, .drv, and others) uses
the PE (Portable Executable) header, which also carry information about the sections in other parts of the file.
In a way, it resembles a sort of index.
One important field is the RVA, or the "relative virtual address". It specifies the offset of the "entry point"
relative to the loadaddress of the file. This sort of "explains" how an executable gets "running".

⇒ .NET program:

From a logical view, .NET executable is an "assembly" and is more or less a selfcontained solution.
It runs "in" the Common Language Runtime (CLR), which is a runtime environment for .Net applications.
The development environments, will take care that the source code get's build to MSIL bytecode,
which "is fit" to run in the CLR environment.
This situation is really somewhat (or quite a lot), from a logical perspective, comparable to the Java platform.

Another thing is, that the .Net programmers do not have to deal with thread management, heaps etc..
that will all be done by the .Net environment. From a hard technical viewpoint, heaps, stacks, threads
are still there, but not in immediate sight of the developer.

Viewed from a "file format" perspective, the executable file has an extended PE header, with CLR sections,
which plays a similar role compared to the traditional executables.
Certainly, a program gets it virtual address space, and the RVA again points to the entry point.
There are entry points (like importing) to .Net core files as well (e.g. mscoree.dll).

7.3 A few words on the network architecture of Windows:

There is no figure about the network architecture, that is fully satisfactory.
In any case, figure 10 is a very lightweight picture of the overall network architecture, without too much details.

Fig 10. High Level overview network architecture.



It's really a sort of lightweight, overall picture, which is valid for all modern Windows versions.
The differences are really in the details. And between Win2K/Win2k3, and Win2K8, they are quite massive.
Indeed, the latest members of the NT family, which are Vista, Win7, and Win2K8, are much more secure.

What you often will find in articles, is a description of abuse of the "Layered Service Provider" (LSP)
implementation. The Winsock API, offers couplings to a "service proivider", to add any sort of
additional functionality. Ofcourse, malware authors were aware of that fact too, so all sorts of
nasty code emerged. A fraudulous LSP can, in principle, intercept and control Internet traffic.
On an infected system, one could for example see that the browser was unintentionally redirected.
The latest Windows versions, seemed to have good control of this feature.

Interestingly, there are many ways to get a view of those providers. Since Vista, Win7,
and Win2K8, for example the "netsh" command has received tremendous capabilities to view
or modify almost all network related settings.
For example, to view your currently installed LSP's, you can use:

C:\TEMP> netsh winsock show catalog

If you are interrested, take a look at the netsh command library:

http://technet.microsoft.com/en-us/library/cc754516(WS.10).aspx

7.4 A few words on IPC, RPC and named pipes:

When you read articles on malware on Windows, it's quite sure you will meet terms like RPC, named pipes etc..
That's why a very short overview is in order, so that we can understand such articles.

7.4.1 RPC:

RPC is short for Remote Procedure Call. It's a high-level protocol. The name already quite expresses
what it really is. An object might "call" a procedure from another (remote) object.
You understand that programmatic objects like .dll's and .exe's, consists of a number of functions,
which might be called from other objects.
RPC is also seen as one of the most important "IPC" (Inter Process Communication) mechanisms.

Also, the word "remote" suggest that procedures might be called from objects residing
on another host (which might even be a completely different platform).
By definition, if the protocol is used with objects in the same environment (the same host/OS),
then often the term Local Procedure call is used. Although most people just talk about RPC in all cases.

RPC is everywhere in Windows. Many objects use RPC to activate functionality from other objects.
It's a high level protocol, that generally "sits" above "sockets", and below the sockets functionality, ofcourse,
the transport layer and the network layer are in place (which usually is TCP IP).
In Windows, RPC actually can use both the "named pipes" or "sockets" implementation.
On this OS, RPC comes with the RPC runtime libraries, which manage most of the details relating to interfacing to
network protocols and details with communication.
A simplified figure is the following:

Fig 11. High Level overview RPC using other components.



The named pipes implementation is a high level protocol as well. So, in many figures, you might see
RPC and named pipes residing in the same level. That's correct, and interpreting figures like fig 11.
in terms of the OSI model, will never be fully satisfactory.
In Windows, it is just simply that RPC might use named pipes, so logically, in this case, we place it below RPC.

RPC is a Client/Server model. The client and Server objects (processes) simply uses a call/response logical model,
where the client calls the remote procedure (while often passing parameters at the same call). The Server then responds
with a certain result.

Now let us try to make a simplistic figure, that gives an idea on the mechanics of RPCs:

Fig 12. High Level overview RPC.



The client and Server processes, might reside on very different platforms, and Operating Systems.
Furthermore, the client and Server might even be programmed with completely different compilers. So, for example,
what the Server process expects to get in terms of data representations, formats, and parameters,
might be very different from what the client think of what should be the right format and representation.
So, at the location of the client and Server, socalled "stubs" has to be present, along with other
rpc runtime libraries, which which will do the neccessary initializations and marshalling.
Just think of marshalling as a way to serialize formats and representations so that it can be correctly understood
by the other object.

- Bindings:

Now what determines the default "protocol bindings" used by RPC? RPC is a high level protocol for
all "sorts of" Client and Server processes. So there generally is a divison between client- and Server protocols.

For the order of bindings of your client processes you might have the the following "ClientProtocols" key, like:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ClientProtocols

where you may see the records:

TCP/IP:   ncacn_ip_tcp
SPX:   ncacn_spx
Named pipes:   ncacn_np
rcp over http:   ncacn_http

But it can also depend on the class of application components.
For example, for "DCOM", which uses RPC, you might have the following registry record "DCOMprotocols" in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc

And you might see values like:

Local RPC:   ncalrpc
TCP/IP:   ncacn_ip_tcp
SPX:   ncacn_spx
Named pipes:   ncacn_np
NetBIOS:   netbios

The "order" of those entries determines, the initial default protocol that will be used.
You might have several of similar locations. If you want more info, you might search the Registry for the value
"ncacn_ip_tcp" or perhaps "RPC_Svr_Binding_Order".

- ports:

If you use TCP/IP, then you will use "ports". A "portmapper", inspects a TCP/UDP segment, and knows which applications
sits on what ports, and will thus transport the segment to the right server or client process.
RPC Server processes will associate their universally unique identifier (UUID) with a dynamic port
and register the combination with the portmapper. In this context the portmapper is called the RPC EndPoint Mapper (EPM).
A client uses the unique identifier to obtain the correct port of the Server process from the EPM.
But, there are still a number of fixed ports though:

Endpoint Mapper: 135
RPC Server: dynamically assigned
Named Pipes: 445

So, in effect, the main "gate" to RPC services is port 135.

- rcpdump:

The rcpdump utility allows us to query the EPM for registered RPC services.
This could help in troubleshooting issues, or for scanning our PC for RPC services.
It's part of the Windows Resource Kit (RK). It's highly advisable to download the RK.
If you have the "Sysinternals suite", and the right RK for your platform,
you will have quite a strong toolset.

As usual with prompt utilities: using it with the /? switch will show you all options.

Let's see a few examples on what we can do using rcpdump:

C:\tools> rpcdump /p ncacn_http
Querying Endpoint Mapper Database...
0 registered endpoints found.

rpcdump completed sucessfully after 2 seconds

C:\tools> rpcdump /I
Querying Endpoint Mapper Database...
RpcMgmtEpEltInqNext:(Access is denied).

rpcdump failed after 1 seconds

So, if I look at the first output, I don't have any RPC server process over http.
As for the second output: On modern Windows versions, the EPM will not allow us, or any program,
to query for all registered services, which is the purpose of the "/I" switch.


7.4.2 DCOM:

We won't say much about DCOM, since it is "more or less" supposed to get phased out, and replaced
by the Dot Net architecture. Not withstanding the fact that much new development is done in Dot Net,
DCOM applications are certainly not obsolete yet. Maybe they never will.

The "Distributed Components Object Model", is an advanced technology which makes it possible that COM objects
communicate, and work together, in a distributed environment (across multiple hosts).
Ofcourse, a DCOM application can work on single host as well.

DCOM objects are RPC clients. Thus they use the RPC framework, as was discussed in section 7.4.1.

If you take a look at figure 10 again, I would say that DCOM fits in (in that figure) as an RPC application.

Many security enhancements in DCOM were introduced as of Win2K3 sp1, as for example using ACL's for COM access,
launch control, and an overall change in the security architecture.
But it's likely quite fair to say that DCOM started to loose the game, in favour of the increasing popularity of Dot Net.

Some articles on the web advise you to kill off DCOM entirely.
I am not sure of that. I am quite reluctant to advise it. If we are dealing with Servers,
it should be tested first on test machines.
Since Win2K3 sp1, and certainly on Win2K8, there is much better security controls, although it's not always easy to find.

One tool that's important for allmost all recent Windows versions, is "dcomcnfg". You can start it from a prompt,
or use "run" from the Start menu.

Fig 13. "dcomcfng" on Win2K8.



If you run another Windows version, the "look and feel" of dcomcnfg may be a little bit different.

If you rightclick "My Computer", you can disable DCOM on older Windows versions, or, on for example Win2K8, you can
modify "Access" and "Launch" permissions. Especially on Win2K8, it seems to be somewhat better compared to old systems:
If you know how to handle NTFS or Share permissions, here it works quite the same:
Remove unneeded security principals (accounts), and add only those which are really needed.
Strangely, the "Everyone" is back again, and that's ofcourse a bit absurd.

Fig 14. "Access and Launch permissions" of DCOM objects on Win2K8.



There are some important Registry settings as well. Take for example a look at the "ole" key in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole

Here you find records like:

"DefaultLaunchPermission"={list in binary}
"MachineLaunchRestriction"={list in binary}
"EnableDCOM"="Y"
etc..

So, "EnableDCOM" sets the global activation policy for the computer.


7.4.3 Named Pipes:

RPC, message passing, shared memory, named pipes etc.. are all important IPC constructs above any suitable network
transport, like TCPIP.

A "named pipe" has quite a few similarities to, for example, how an application works with a remote mounted filesystem,
or network share.
It goes even so far, that many engineers talk about the named pipe filesystem (NPFS), mounted under
the special path \\.\pipe\.
The named pipe uses a semantics much like accessing a "regular" file. So, functions such as ReadFile, WriteFile
can be used to read from or write to the pipe.

So, referring again to fig.11: The RPC mechanisme uses some sort of locator services to find the objects it needs
to communicate with.
Next, a pipe is created, which both the Client and Server processes can access to read and write from.
Next, the usual network transport comes into action like TCP segments, IP addressing etc..


This concludes our short and simple technical "survey" of Windows systems.
We should be able to understand articles, related to Windows security, a little bit better now.

8. How to list patches and security updates

There are different sorts of Windows Updates, like updates that corrects bugs and errors (patches, hotfixes).
A special class of updates however, are the security updates.

Associated with a security update, is a "Microsoft Security Bulletin" with a naming standard of
MSxx-yyy, like for example "MS08-067", where the "xx" is the year when the Bulletin was published. Apart from the description (the Bulletin), the actual patch might have a name that you might
not directly associate with the Bulletin identifier. For example, for Bulletin "MS08-067", a security patch
was released, which was generally named "958644" or "KB958644" (which refers to the Knowledge Base number).

But hold on. We are not there yet. Since different Windows versions (with different Service Pack) exists,
the true patch name will reflect those differences for versions too.
So, for example, the patch 958644 for Windows XP SP3 (x86), is called "WindowsXP-KB958644-x86-ENU.exe",
while the same patch for Win2K3 SP2 (x86) is called "WindowsServer2003-KB958644-x86-ENU.exe".

So, as a good identifier for Windows security patches, we will use the generic name like e.g. KB958644.

Note:
Apart from Manufacturer specific identifiers, a globally unique name exists as well, which is a "CVE" identifier.
CVE is short for "Common Vulnerabilities and Exposures".

Note:
Exploits are sometimes also described, or charcterized, by the "attack vector" used.
Such an attack vector then globally describes the most distinguising feature of the exploit,
or the way it gets activated.
So, you may hear people speak of "Startup folder" vector, or "heap overflow" vector etc...

Listing patches:


Method 1:

One simple way is using the "systeminfo" command, which almost all recent Windows systems
have available. For example:

C:\TEMP> systeminfo | find "KB958488"

Where you explicitly want to check on the existence of patch "KB958488".

If you want a list of all updates, use:

C:\TEMP> systeminfo | find "KB"


Method 2:

Here we use our old friend, the WMIC command, again.
You can try a command like this:

C:\TEMP> wmic qfe list full > updates.txt


Method 3:

Depending on your Windows version, you can easily, or not so easily, find information on updates
in the Registry too.

- For example, for Win2K3 it relatively simple. You can browse at locations like:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows Server 2003\SP3\
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

- For Win7, Win2K8, retrieving the information seems to be somewhat more elaboate.


Method 4:

Just view the "WindowsUpdate.log" file in %SYSTEMROOT%. For example:

C:\TEMP> copy C:\WINDOWS\WindowsUpdate.log # just get a copy in C:\TEMP

C:\TEMP> notepad WindowsUpdate.log

Although it's a rather complicated file, you can search (for example) for a certain KB number.


Method 5:

The Powershell "Get-Hotfix" cmdlet, can show the hotfixes that have been applied to your local system,
or even remote systems.

Task:

I have a nice task for you. You probably have "powershell" on your machine. You can easily test that by
entering powershell from the prompt. The prompt will then per default change to "PS directoryname",
where the directory name, the directory is where you (from the prompt) called powershell from.
Task: create, or find (using the Internet), a powershell script that will show the fixes installed on your system.


Note:
It's a bit trivial, but ofcourse you can use Control Panel as well, to view all updates that are applied to
your system. It works a bit different between XP/Win2K3 and Vista/Win7/Win2K8, but you can just
browse around in the "Installed Programs" or "Software" applet (or whatever it might be called in your control panel)
Also, the graphical "Windows Update History" can be quite informative.

Note:
This is probably quite trivial too: To get the version of your operating system, and installed Service packs,
you can use the "winver" or "systeminfo" command. Both will list the version, the buildnumber, and
which Service Packs(s) are installed.

Note:
With older Windows versions, directly under %SYSTEMROOT%, you might find a number of "$NTUninstallKBnumber"
directories, which corresponds to the installed updates to your system. So, this information can be used too.

9. Description of some well known (but often patched) vulnerabilities in Windows.

Note: chapter 9 gets updated quite often.

The following listing of well-known (older) vulnerabilities might be interesting.
Ofcourse, the vulnerabilities we will see in this section, are all "patched away",
if you have a recent Windows version, and indeed applied all neccessary service packs and security updates.

9.1 AppInit DLL:

Once considered to be a source of concern, this has eased a lot nowadays. But, it's still worth checking
if you want to investigate a system.

The Registry value of "AppInit_DLLs" found in

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows

specifies a list of dll's that MS programs will load, if they are linked with user32.dll.
Ofcourse, this could be "good" or "bad". Nowadays, programmers would not use this mechanism anymore,
but if they do, they should have a good explanation for it.

On your system, it should be empty. If not, it's worth investigating why not.

On modern systems, a second record can be found, namely "LoadAppInit_DLLs", which functions as a switch
whether the AppInit DLL loading mechanism is active (value is 1), or not (value is 0).

9.2 Netbios NULL sessions:

This is a problem of possibly illegal "enummaration", which means that an unauthorized person or entity
could obtain lists of network resources like e.g. "shares", "machinenames", "account names" etc..

Having such lists, it could help an unauthorized person to decide on "the next bad steps".
Surely, you probably do not want to "help" such persons in any way.

A problem is, that the enummaration is provided by quite a few Windows modules.
For example, the "WNetEnumResource" function can be called from the "mpr.dll" library,
and many modules can do so.

Two of the most important ones are enummeration through Netbios and SMB (Server Message Block).
Netbios is most of the time viewed by network experts as a sort of Session manager, residing in OSI layer 5.
SMB then, is often viewed as an application protocol, residing in the Application layer (layer 7).

SMB comes into action, when shared resources (like file- and printservices) are provided or accessed.
And in some cases, it's also used in some IPC mechanisms, like the "named pipes" ipc, using SMB functions.
So, SMB, partly specialized in access to remote filessystems, and another part deals with IPC mechanisms.
One special one used in IPC communication, is the "hidden" IPC$ share, which is used in certain interprocess
(named pipes) communication.

To go to "the wire", SMB might use or Netbios and lower protocols other than TCPIP, or
directly using sockets/TCPIP, or Netbios and sockets/TCPIP.
It is like this: SMB operates over

• SMB using 139/TCP (NetBIOS over TCP/IP transport)
• SMB using 445/TCP (raw SMB transport, directly into TCP)

Furthermore, Netbios Session Service, or Netbios Naming Services (NBNS) uses:.

137/TCP Netbios Name Service
137/UDP Netbios Name Service
138/UDP Netbios Datagram Service
139/TCP Netbios Session Service
139/UDP Netbios Session Service


Ofcourse, any firewall should have blocked traffic on these ports. In fact, usually only a few selected ports
are enabled.

Netbios handles, among other things, session management and (netbios) names/resource resolution.
Since Win2000, the importance has diminished, but even in Win2K8, it's still not gone. First, using for example
SMB for accesing shares, could use netbios, unless you have disabled that. Secondly, some IPC mechanisms might still
use Netbios also. However, on modern systems you can disable Netbios over TCPIP.

There are many commandline tools available to list network rescources (accounts, machines, shares etc..),
where the standard "net command" is the most famous. But many tools are around like the old "enum" tool,
or even the (graphical) "ShareEnum" tool from the sysinternals suite.

Suppose you are an authenticated user (for example through an Active Directory logon). You can start a prompt session
and use commands like for example:

C:\TEMP> net view \\servername

This (probably) will show you all shares that are provided by the Server "servername" on your subnet.
This ain't so bad (although quite a few people would not agree with that), because you are an authenticated user.
Although it's certainly true that many SysAdmins will have restriced access to commands in place, for "common" users.

It's getting really bad, if somebody just plugs in a Laptop on your network (using the right IP parameters),
and that person would be able to retrieve all sorts of lists of resources.

Note: a modern and secure network infrastructure would make that scenario quite unlikely, that is, that
somebody could just connect a foreign device on your network. Many switches can be configured to not allow
just any device on just any port.

One special case is the "Netbios NULL Session", using the "ipc$" share. It's called a null session
because a null account (and null password) is used for authentication. In fact, it is equivalent to "Anonymous access".
Actually it should be called a SMB null session, since SMB is the driving force around it.

If you would try this (as an anonymous user):

C:\TEMP> net use \\servername\ipc$ "" /u:""

Then in principle, it could be possible that anonymous users could retrieve lists from your system(s)

Remedy: Check if you can adjust the computer policy on Servers and DC's, like for example:

- Network: anonymous SID / Name translation - Disabled
- Network access: Do not allow anonymous enumeration of SAM accounts - Enable It
- Network access: Do not allow anonymous enumeration of SAM accounts and shares - Enable It
- Network access: Let Everyone permissions apply to anonymous users - Disable It
- Network access: Named Pipes that can be accessed anonymously - None
- Network access: Shares that can be accessed anonymously - None

And ofcourse, make sure you have blocked all ports as was shown above.


The following few sections deals on "memory corruption" of different sorts.
Several types are possible, like Stack overflow, or changing a pointer of a
control structure like the "PEB" (explained later), or overwriting area's in the heap (or pointers within),
all with the aim of transferring control to "shellcode" (explained later), or just simply trashing.

9.3 Heap Overflows - 1. PEB tampering:

You might recall from section 7.2.6, that we can distinguish between stacks and heaps as memory area's for a process.
A heap is a larger memory area where dynamic objects are allocated. Usually, one or two heap areas are created.
A stack is more or less sort of small scratch space (for variables of functions) for every thread of execution.

Some other "control sections" exists as well, like the PEB, which stores all sorts of specifics of the process
and the heaps.

As you can read in many articles on the subject, the "organization" around stacks and heaps changed significantly
as of XP SP2 and Win2k3 SP1.
To summarize the differences:

(1): The heaps and all associated structures were much less checked in the pre XP SP2 period.
(2): As of XP SP2, DEP (Data Execution Prevention) may mark certain memory area's as non-executable.

One technique to let malware execute and gain control in the pre XP SP2 period, was the following.

When a process gets created, various things are loaded or created by Windows, among which is the
"Process Environment Block" or "PEB" (see also section 7.2.7).
The PEB may be considered as a sort of index, and it contains all User-Mode parameters associated with the process.
It contains heap information, information on loaded modules, pointers to specialized functions etc..
One of those functions is "FastPebLockRoutine", which can be called when regular code needs to lock the PEB
in order to modify the index if a relevant change has happened.
Since the PEB is in the user area, it was writable by everything that wanted to write in it.

Now, overwriting an address in the PEB, and placing a payload in free pages in the PEB, or heap,
could result in a situation where some malware get executed and gained full control of your system.

In such situations, the "payload" often is called "shellcode". This name originates more or less from "historic" reasons,
since originally in some cases true shell code was implemented. However, in general, any type of code
can form this shellcode (the payload), as long as it is executable.

So, if the FastPebLockRoutine could be made to point to the location of the shellcode, then in principle that shellcode
could be activated whenever the routine was called.

If the above was indeed realized, it was just matter of time before that routine was called, or, if the attacker was also
able to overwrite another essential control, then an execption was raised resulting in the program termination.
However, as a part of the termination, also the FastPebLockRoutine was called, resulting in transfer of execution
to that shellcode.

As of XP SP2 / Win2k3 SP1, Microsoft have removed some elements of the PEB, so that the above technique is not effective
anymore for those Windows versions and above. Specifically, the PEB has been randomized, and the obvious pointers
to new versions of FastPEBLockRoutine() and FastPEBUnlockRoutine() (which were at the well documented PEB offsets
0x020 and 0x024), have been removed.

9.4 Heap Overflows - 2. Heap sprays:

Be short on this one. Simplified, it means that if it would be possible to reorganize, or coalesce,
the (default) heap in equally sized chunks, and "spray" (meaning copy/filling) it with many copies (thousends?)
of some payload, and if the attacker would be able to shuffle (maybe even randomly) some pointers, there is a slim chance
the execution pointer "lands" on some payload, somewhere.

Some real examples have been demonstrated using javascript.

This is still an active field of research.

9.5 Stack Overflows:

If you ever have programmed, you probably have seen it a lot yourself: stack overflow.

Especially with "older" development environments (like an older "C" compiler), it's not very difficult
to trash a stack, in which case the program (should) terminate.
So what's the big deal here?

For security, it's not likely to be a hard issue anymore, although ofcourse one should "never say never".

Although stack overflow usually is associated with the fact that the stack tries to exceeds it's boundary,
the term is used also for an event as described below.

Canonical method:

One simpilistic (old) method would be that in a certain function, a variable is declared of a certain size,
and subsequently then assigned a larger value to that variable. Once placed on the stack, the larger value might
overwrite another variable or even a return address. In case of the latter, it would be possible
that the overwritten pointer is popped from the stack, and execution transfers to that location in memory,
where the "shellcode" resides.

One important question remains on how to precisely inject the address in the right place.
Well, first of all: do never underestimate hours of "guessing, observing with debuggers, calculating, and luck".

It would be possible only with very old compilers, or if the protection is deliberately set to "off".
One form of protection would be that at certain locations in the stack frame, certain codestrings ("canaries")
are present (as a sort of guards) in order to detect this sort of trashing.
If such an 'out of bound" event occurred, before a return pointer could be overwritten,
such string would be damaged, and the program was terminated immediately.

In some environments, one can compile a program using a specific argument to enable or disable this type
"stack smashing" protection, like for example "gcc -fno-stack-protector myprg.c", which disables it.

Note: Microsoft has integrated canaries in their stack too, as of XP SP2.

Return to libc method:

As the description already implies (note the "libc"), this method is more familiar
in Unix and Linux environments. In these environments, certain kernel settings may introduce
randomizations, or may mark stacks (or memory area's in general) as "non-executable".
If a stack is not executable by itself, it still works as usual but you are not allowed to execute from it.
So, if you want to transfer control to your illegal code, you need another method. One such method was
named "return to libc", which is a nifty way to use systemfunctions for your purposes.
You even do not have to fill a large buffer with your shellcode, but directly misuse systemfunctions instead.
One very simple example would be, that you would be able to deduce the address of system() and an address
holding a string like "/bin/sh", which might create a situation where a shell get's executed.

Modern Windows versions too, may use non-executable stacks (and heaps). For this, the processor must support
the feature of making memory area's non-executable. For this to happen, the NX bit (No eXecute) must be flagged "on".

As of XP SP2, the feature is implemented and called "Data Execution Prevention" (DEP).
You can configure DEP through the advanced tab of "System" properties.

Note:
Ofcourse, all modern cpu's will support the NX (or similar) flag. If not, even software based solutions exists.

9.6 Tampering TCPIP and LSP:

Appendix A. Links from where to download.

Dependency Walker
Sysinternals suite
xvi32 hexeditor
hexdump32 hexviewer
Cygwin linux for Windows
Moonsols memory dump kit (community edition)
Win2K3 Resource Kit tools

Appendix B. Listing KB numbers / MSxx Bulletins.

If you want, you can view a rather large listing of KB numbers or MSxx Bulletins
with a short description, and in which Service Pack for which OS, they were employed.

Listing of fixes and associated KB numbers / Bulletins