The Attack and Defense of Computers

1

• ???????
• The Attack and Defense of Computers
• Dr. ? ? ?

2

• Rootkit

3

• for Windows by Bryce Cogswell et al.

4
Categories of Rootkits Windows

• User-mode Rootkits
• Kernel-mode Rootkits

5

• User-mode Rootkits

6
Windows API wikipedia

• The Windows API, informally WinAPI, is the name
  given by Microsoft to the core set of application
  programming interfaces available in the Microsoft
  Windows operating systems.
• It is designed for use by C/C programs.
• It is the most direct way to interact with a
  Windows system for software applications.

7
Windows API and DLL developerfusion

• Windows can do lots of things
• manage hardware
• run programs
• display icons
• Much of these functions are carried out by
  DLL files.
• DLLs (Dynamic Linked Libraries) store functions,
  so other programs can access them.
• The advantage of using DLLs is that the same file
  can be accessed at the same time by different
  programs.
• The functions stored in the windows DLLs are
  called Windows API.

8
Native APIwikipedia-1 wikipedia-2

• Lower level access to a Windows system, mostly
  required for device drivers, is provided by the
  Native API in current versions of Windows.
• The Native API (with capitalized N) is the
  publicly undocumented/incompletely documented
  application programming interface used internally
  by the Windows NT family of operating systems.

9
Windows Library Files -- user32.dllanswers.com

• user32.dll is a file that contains Windows API
  functions related the Windows user interface,
  such as
• Window handling
• basic UI functions
• and so forth.
• It is a core file for several versions of the
  Microsoft Windows operating system.
• If this file is damaged or deleted, the operating
  system will not work.

10
Windows Library Files -- ntdll.dll answers.com

• Most of Native APIs are in ntdll.dll and
  ntoskrnl.exe (and it's variants).

11
Native Applications answer

• Applications that are linked directly against a
  Native API library are known as Native
  Applications
• the primary reason for their existence is to
  perform low-level tasks such as direct disk I/O
  that cannot be achieved through the documented
  Windows API.
• Ordinary Windows applications are not linked
  directly against a Native API library, but to one
  or more of the WinAPI libraries with
  well-documented APIs
• This is to retain portability across Windows
  Platforms among other reasons.

12
User-mode Rootkits Utilizing Windows APIs

• A user-mode rootkit might intercept all calls to
  the Windows FindFirstFile/FindNextFile APIs which
  are used by file system exploration utilities to
  enumerate the contents of file system
  directories.
• The above utilities include Explorer and the
  command prompt.
• When an application performs a directory listing
  that would otherwise return results that contain
  entries identifying the files associated with the
  rootkit, the rootkit intercepts and modifies the
  output to remove the entries.

13
API Hooking craigheffner

• In Windows, all applications must communicate
  with the kernel through API functions as such,
  these functions are critical to even the simplest
  Windows application.
• Thus, the ability to intercept, monitor, and
  modify a program's API calls, commonly called API
  hooking, effectively gives one full control over
  that process.
• This can be useful for a multitude of reasons,
  including
• debugging
• reverse engineering
• hacking.

14
A Method to Intercept API Calls

• While there are several methods which can be used
  to intercept, monitor, and modify a program's API
  calls, one of them is DLL redirection.

15
DLL Redirection craigheffner

• Since an executable imports API functions from
  DLL files, DLL redirection allows us to tell a
  program that the DLLs it needs are located in a
  different directory than the originals.
• In this way we can create a DLL with the same
  name as the original, which exports the same
  function names as the original, but each function
  may contain whatever code we like.

16
User-mode Rootkits Utilizing Windows Native APIs

• More sophisticated user-mode rootkits intercept
  file system, Registry, and process enumeration
  functions of the Native API.
• This prevents their detection by scanners that
  compare the results of a Windows API enumeration
  with that returned by a Native API enumeration.

17
Registry Microsoft

• A central hierarchical database used in Microsoft
• Windows 9x
• Windows CE
• Windows NT
• Windows 2000
• used to store information necessary to
  configure
• the system for one or more users
• applications
• hardware devices.
• Registry data is stored in binary files.

18
Functions of Registry Russinovich and Solomon

• The Registry is a the system database that
  contains
• the information required to boot and configure
  the system
• system-wide software settings that control the
  operation of Windows
• the security database
• per-user configuration settings (such as which
  screen saver to use)
• The Registry is a window into in-memory volatile
  data, such as
• The current hardware state
• Windows performance counters

19
Information Contained in the Registry Microsoft

• The Registry contains information that Windows
  continually references during operation, such as
• profiles for each user
• the types of documents that each application can
  create
• what hardware exists on the system
• the ports that are being used
• the applications installed on the computer
• property sheet settings for folders and
  application icons

20
Description of the Registry Microsoft

• The Registry replaces most of
• the text-based .ini files used in Windows 3.x
• and
• MS-DOS configuration files such as
• Autoexec.bat
• and
• Config.sys.
• Although the Registry is common to several
  Windows operating systems, there are some
  differences among them.

21
Use regedit to Look at the Registry Tim Smith

• The Registry is stored on your hard disk in
  several files but the only way to look at it and
  make changes is to use the regedit program.
• To access this, click on the Start Button and
  then on the Run option.
• Type regedit into the box that appears and press
  Enter.
• This will launch regedit and you will now have
  your first sight of the Registry.

22
Constitute Elements of the Registry wikipedia

• The registry contains two basic elements
• keys
• values

23
Organization of Registry Tim Smith

• The Registry is organized much like the files on
  a disk and will look familiar if you have ever
  used the Folders view in Windows Explorer.
• In the Registry, however, these folders are
  called keys.
• Each key can contain subkeys, which may contain
  further subkeys, and so on.
• To open a key, simply click on the small plus ()
  symbol next to it. You will then see that each
  key contains
• either more keys - called subkeys
• or values.

24
Predefined Keys Microsoft

• What follows is the predefined keys that are used
  by the system.
• HKEY_CURRENT_USER (abbr. HKCU)
• HKEY_USERS (abbr. HKU)
• HKEY_LOCAL_MACHINE (abbr. HKLM)
• HKEY_CLASSES_ROOT (abbr. HKCR)
• HKEY_CURRENT_CONFIG (abbr. HKCC)
• The maximum size of a key name is 255 characters.

25
Key Value wikipedia

• Any key may contain values. These values can be
• String Value
• Binary Value (0 and 1's)
• DWORD Value, a 32 bit unsigned integer (numbers
  between 0 and 4,294,967,295 232 1)
• Multi-String value
• Expandable String Value
• Registry values are name/data pairs stored within
  keys.
• Values are referenced separately from keys.

26
Key Hierarchy wikipedia

• Each key has a default value, which is in effect
  a value with the same name as the key.
• Registry keys and values are specified with a
  syntax similar to Windows' filenames, using
  backslashes to indicate levels of hierarchy.
• E.g. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
  refers to the subkey "Windows" of the subkey
  "Microsoft" of the subkey "Software" of the
  HKEY_LOCAL_MACHINE key.

27
Example (1)
The name/data pair of a value
HKCU has subkeys and values. By pressing the
before the HKCU you can see its subkeys.
28
Example (2)
29
Key Specifying Applications to Run When a User
Logs in wikipedia

• HKLM\Software\Microsoft\Windows\CurrentVersion\Run
  (and the HKCU equivalent) specifies applications
  to run whenever a user logs in.
• These can include
• desirable programs
• such as printer monitoring programs
• or
• frequently-used tools
• But a lot of malware uses this registry key to
  ensure it is automatically run.
• This key is a good place to start looking for
  evidence of malware if you think your computer
  has been infected.

30
Example
31
Spyware and Registry Tim Smith

• Spyware often installs values in the Registry to
  make sure that it's launched to monitor your
  computer when Windows starts up.
• When looking for advice on how to remove these
  programs you may be told to edit the Registry.
• Always make sure that the advice is coming from a
  trustworthy source such as Registry Guide for
  Windows.
• Sometimes the spyware also installs a small
  program to monitor the Registry and replace keys
  that you delete, so you should use software such
  as Spybot Search and Destroy to clean your
  computer entirely.

32

• Kernel-mode Rootkits

33
Kernel-mode Rootkits

• Kernel-mode rootkits can be even more powerful
  since
• not only can they intercept the Native API in
  kernel-mode
• but they can also directly manipulate kernel-mode
  data structures.

34
Hiding the Presence of a Malware Process

• A common technique for hiding the presence of a
  malware process is to remove the process from the
  kernel's list of active processes.
• Since process management APIs rely on the
  contents of the list, the malware process will
  not display in process management tools like Task
  Manager or Process Explorer.

35

• Rootkit Techniques by Ivo Ivanov

36
Techniques Involved

• Step 1 Injecting techniques
• Step 2 Interception Mechanisms

37

• Injecting Techniques Ivo Ivanov

38
Injecting Techniques

• Method 1 Registry
• Method 2 Global Windows Hooks
• Other Methods(omitted in this lecture)
• Injecting DLL by using CreateRemoteThread() API
  function
• Implanting through BHO add-ins
• MS Office add-ins

39

• Inject by Registry

40
Inject a DLL into Processes

• In order to inject a DLL into processes that link
  with USER32.DLL, you simply can add the DLL name
  to the value of the following registry key
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
  NT\CurrentVersion\Windows\AppInit_DLLs
• Its value contains
• a single DLL name
• or
• group of DLLs separated either by comma or
  spaces.
• According to MSDN documentation, all DLLs
  specified by the value of that key are loaded by
  each Windows-based application running within the
  current logon session.

41
Invoke Registry Editor
42
Select the Appropriate Key
43
Edit the Selected Key
44
Load USER32-Related DLLs

• It is interesting that the actual loading of
  these DLLs occurs as a part of USER32's
  initialization.
• In its DllMain code, USER32
• reads the value of mentioned registry key
• and
• calls LoadLibrary() for these DLLs.
• Restrictions
• However this trick applies only to applications
  that use USER32.DLL.
• Another restriction is that this built-in
  mechanism is supported only by NT and 2K
  operating systems.

45
Shortcomings

• In order to activate/deactivate the injection
  process you have to reboot Windows.
• The DLL you want to inject will be mapped only
  into these processes that use USER32.DLL.
• Thus, you cannot expect to get your hook injected
  into console applications, since they usually
  don't import functions from USER32.DLL.
• On the other hand you don't have any control over
  the injection process.
• It means that it is implanted into every single
  GUI application, regardless you want it or not.
• It is a redundant overhead especially if you
  intend to hook few applications only.

46

• Inject by Hooks Chris Cummings

47
What Are Hooks?

• Put shortly, a hook is a function you can create
  as part of
• a dll
• or
• your application
• to monitor the 'goings on' inside the
  windows operating system.
• The idea is to write a function that is called
  every time a certain event in windows occurs.
• For example when a user presses a key on the
  keyboard or moves the mouse.
• Hooks were provided by Microsoft primarily to
  help program writers with the debugging of their
  applications, but they can be put to use in many
  different ways.
• For example, write hidden key logging program to
  find out other users passwords to the internet!

48
Types of Hooks

• There are 2 types of hooks - global or local.
• A local hook is one that monitors things
  happening only for a specific program (or
  thread).
• A global hook monitors the entire system (all
  threads).
• Both types of hooks are set up in the same way,
  the main difference being
• for a local hook, the function to be called can
  be within the program it is monitoring
• but with a global hook the function must be
  stored and loaded from a separate dll.

49

• Hook-related Functions

50
The SetWindowsHookEx Function

• SetWindowsHookEx is the function provided by
  Microsoft to install a hook. It accepts the
  following arguments
• SetWindowsHookEx returns a handle (i.e. an
  identifier) for the current hook, so you can use
  UnhookWindowsHookEx to remove the hook later on.

51
SetWindowsHookEx Example Michel Leunen

• // Hood Function (Callback Procedure) Declaration 
  LRESULT CALLBACK MouseProc(int code, WPARAM wPara
  m, LPARAM lParam)
• // Global variables HHOOK HookHandle HINSTANCE 
  DllInstance bool IsInRectfalse 
• bool InstallMouseHook() 
• HookHandleSetWindowsHookEx(WH_MOUSE, 
•    reinterpret_castltHOOKPROCgt(MouseProc),DllInsta
  nce,0)
• if (HookHandleNULL)
• return false
•   else 
• return true
• //------------------------------------------------
  --------------------
• bool RemoveMouseHook()
•   if(UnhookWindowsHookEx(HookHandle)0)
•        return false
•   else 
• return true
•  

52
Types of Hooks used in idHook Parameter of a Hook
Function

• Types of Hooks appearing in a hook function.

53
The Hook Function

• The hook function is the procedure to be called
  by windows when the event we specify happens.
• A hook for any event always takes the same form,
  but the values passed to it by windows can mean
  different things.
• For example if the hook is type WH_KEYBOARD,
  windows will pass information to it relating to
  which key was pressed.
• Your hook procedure should accept the following
  arguments
• A hook function returns a value of type longword.
  What you should set it to depends on the type of
  hook, or you can just set it to the value that
  CallNextHookEx returns.

54
Hook Function Example

• LRESULT CALLBACK MouseProc(int code, WPARA
  M wParam, LPARAM lParam)    if (codelt0)     
     return CallNextHookEx(HookHandle,code,wParam,lP
  aram)      //Define a rectangle   POINT Mouse
  Pos   RECT UpperRightCornerRect(Screen-gtWidth-2
  ,0,Screen-gtWidth,2)   //Get the mouse position 
    GetCursorPos(MousePos)   //Check if the mouse
   is in the rectangle   if((PtInRect(UpperRightCo
  rner,MousePos))(IsInRectfalse))        //if
   the mouse is in the rectangle, launch the screens
  aver     IsInRecttrue     SendMessage(GetDeskt
  opWindow(),WM_SYSCOMMAND,SC_SCREENSAVE,0)     
  else IsInRectfalse   //Call the next hook in th
  e chain   return CallNextHookEx(HookHandle,code,w
  Param,lParam) 

55
The CallNextHookEx Function

• This function is to do with hook chains.
• When a hook is installed for a certain event,
  there may be others like it already installed.
• For example 2 programs at once might be trying to
  log keyboard input.
• When you install a hook with SetWindowsHookEx it
  adds your hook procedure to the front of a list
  of hook procedures. CallNextHookEx simply calls
  the next procedure in the list.
• When your hook procedure is finished, it can run
  CallNextHookEx, and then return
• the value it gets from it
• or
• a different one depending on the type of hook.
• CallNextHookEx takes exactly the same form as a
  hook procedure plus one extra
• the handle returned by SetWindowsHookEx
  identifying the hook.
• The other values you pass to it should be the
  values your hook procedure was called with. How
  you should use it depends on the type of hook

56
The UnhookWindowsHookEx Function

• This function simply removes your hook.
• The only argument you pass to it is the hook
  handle returned by SetWindowsHookEx.

57

• Global Windows Hooks

58
Global Hooks

• The global hook is slightly more complicated than
  a local hook.
• To create a global hook you need 2 steps,
• to make the executable file that executes
  SetWindowsHookEx()
• to make a Dll to contain the hook procedure.

59
System-wide Hooks

• A system-wide hook is registered just once when
  SetWindowsHookEx() is executed.
• If no error occurs a handle to the hook is
  returned.
• The returned value is required at the end of the
  custom hook function when a call to
  CallNextHookEx() has to be made.
• After a successful call to SetWindowsHookEx(),
  the operating system injects the DLL
  automatically (but not necessary immediately)
  into all processes that meet the requirements for
  this particular hook.

Processes that will encounter the same event as
the event indicated in the hook function.
60
Global Variables vs. Shared Data

• Once an application installs a system-wide hook,
  the operating system maps the DLL into the
  address space in each of its client processes.
• Therefore global variables within the DLL will be
  per-process and cannot be shared among the
  processes that have loaded the hook DLL.
• All variables that contain shared data must be
  placed in a shared data section.

61
A Global Hook Is Loaded by Multiple Processes
That Don't Share the Same Address Space

• For instance hook handle sg_hGetMsgHook, that is
  obtained by SetWindowsHookEx() and is used as
  parameter in CallNextHookEx() must be used
  virtually in all address spaces.
• It means that its value must be shared among
  hooked processes as well as the hook Server
  application. In order to make this variable
  "visible" to all processes we should store it in
  the shared data section.

62
Define Variables Shared by All Processes
63
Example

• Installing a mouse hook.

64

• Interception Mechanisms Ivo Ivanov

65
Interception Mechanisms

• Injecting a DLL into the address space of an
  external process is a key element of a spying
  system.
• It provides an excellent opportunity to have a
  control over process's thread activities.
• However it is not sufficient to have the DLL
  injected if you want to intercept API function
  calls within the process.

66
Interception through Special Kinds of Hooking

• In terms of the level where the hook is applied,
  there are two mechanisms for API spying
• Kernel level spying
• through NT Kernel Level Hooking
• User level spying
• Win32 User Level Hooking

67
The Module Relationships and Their Dependencies
on Windows 2K and Interception Points
68

• NT Kernel Level Hooking

69
NT Kernel Level Hooking

• There are several methods for achieving hooking
  of NT system services in kernel mode.
• The most popular interception mechanism was
  originally demonstrated by Mark Russinovich and
  Bryce Cogswell in their article "Windows NT
  System-Call Hooking".
• Their basic idea is to inject an interception
  mechanism for monitoring NT system calls just
  bellow the user mode.
• This technique is very powerful and provides an
  extremely flexible method for hooking the point
  that all user-mode threads pass through before
  they are serviced by the OS kernel.
• However, all these hooking strategies, remain out
  of the scope of this course.

70

• Win32 User Level Hooking

71
Win32 User Level Hooking

• Proxy DLL (Trojan DLL)
• Spying by altering of the Import Address Table
• Other Approaches (not covered in this lecture)
• Code overwriting
• Spying by a debugger
• Windows sub-classing

72

• Function Forwarder -- Mechanism Used by Proxy
  DLLJeffrey Richter

73
Define a Function Forwarder
Defined in a stub DLL (A stub DLL refers to an
entire DLL of unimplemented functions.)

• // Function forwarders to functions in DllWork
• pragma comment(linker, "/ exportSomeFuncDllWork
  .SomeFunc")
• This pragma tells the linker that the stub DLL
  should export a function called SomeFunc, but
  that the actual implementation for the function
  is in a function SomeFunc contained in the
  DllWork.dll.
• You'll have to have one pragma line for each
  function exported by your DllWork.dll for a
  program to call your functions correctly.

74
Stub DLL and the Real DLL
stub DLL
pragma comment(linker, "/exportSomeFuncDllWork.
SomeFunc") BOOL WINAPI DllMain (HINSTANCE
hinstDll, DWORD fdwReason, LPVOID p)
ShutdownLibrary() return(TRUE)
The DLL used by an application
The real DLL
__declspec(dllexport) void ShutdownLibrary()
__declspec(dllexport) void SomeFunc() void
SomeFunc() MessageBox(NULL, "Doing something",
"SomeFunc in DllWork", MB_OK) void
ShutdownLibrary() // Notify the worker threads
to shutdown SetEvent(g_hEventTerminate)
BOOL WINAPI DllMain (HINSTANCE hinstDll, DWORD
fdwReason, LPVOID fImpLoad) int nThread

LoadLibrary loads the stub DLL, then the OS
loader automatically loads your real DLL.
75
_declspec wikipedia

• the _declspec keyword is a strange new keyword
  that is not part of the ANSI C standard, but that
  most compilers will understand anyway.
• _declspec allows a variety of non-standard
  options to be specified, that will affect the way
  a program runs. specifically, there are two
  _declspec identifiers that we want to discuss
• _declspec(dllexport)
• _declspec(dllimport)

76
Dllexport wikipedia

• When writing a DLL, we need to use the dllexport
  keyword to denote functions that are going to be
  available to other programs.
• Functions without this keyword will only be
  available for use from inside the library itself.

77
DllMain wikipedia

• When Windows links a DLL to a program, Windows
  calls the libraries' DllMain function. This means
  that every DLL needs to have a DllMain function.

78

• Function Forwarder Example

79
Function Forwarder

• A function forwarder is an entry in a DLL's
  export table that redirects a function call to
  another function in another DLL.
• For example, if you run the Visual C DumpBin
  utility on the Windows NT Kernel32.dll, you'll
  see a part of the output that looks like this
• C\winnt\system32gtDumpBin -Exports
  Kernel32.dll
• (some output omitted)
• 360 167 HeapAlloc (forwarded to
  NTDLL.RtlAllocateHeap)
• 361 168 HeapCompact (000128D9)
• 362 169 HeapCreate (000126EF)
• 363 16A HeapCreateTagsW (0001279E)
• 364 16B HeapDestroy (00012750)
• 365 16C HeapExtend (00012773)
• 366 16D HeapFree (forwarded to
  NTDLL.RtlFreeHeap)
• 367 16E HeapLock (000128ED)
• 368 16F HeapQueryTagW (000127B8)
• 369 170 HeapReAlloc (forwarded to
  NTDLL.RtlReAllocateHeap)
• 370 171 HeapSize (forwarded to
  NTDLL.RtlSizeHeap)
• (remainder of output omitted)

80
How a Function Forwarder Forwards the Execution
of a Function to Another Function

• This output of the previous slide shows four
  forwarded functions.
• Whenever your application calls HeapAlloc,
  HeapFree, HeapReAlloc, or HeapSize, your
  executable is dynamically linked with
  Kernel32.dll.
• When you invoke your executable, the loader loads
  Kernel32.dll and sees that there are forwarded
  functions that are actually contained inside
  NTDLL.dll, so the loader also loads the NTDLL.dll
  module.
• When your executable calls HeapAlloc, it is
  actually calling the RtlAllocateHeap function
  inside NTDLL.dll.
• The HeapAlloc function does not actually exist
  anywhere in the system!

81
Rootkits Utilizing Function Forwarders -- Proxy
DLL (Trojan DLL) Rootkits

• An easy way for hacking API is just to replace a
  DLL with one that has the same name and exports
  all the symbols of the original one.
• This technique can be effortlessly implemented
  using function forwarders.
• However, if you decide to employ the above
  method, you should take the responsibility of
  providing compatibilities with newer versions of
  the original library.

82

• Portable Executable File Format Ashkbiz Danehkar
  

83
Portable Executable File Format

• The Portable Executable file format was defined
  to provide the best way for the Windows Operating
  System
• to execute code
• to store the essential data which is needed to
  run a program
• for example
• constant data
• variable data
• import library links
• resource data
• It consists of
• MS-DOS file information,
• Windows NT file information,
• Section Headers,
• and Section images.

84
Portable Executable File Format Structure (1)
85
Portable Executable File Format Structure Types
MS-DOS Information
IMAGE_DOS_HEADER
MS-DOS Stub Program
Windows NT Information
Signature (IMAGE_NT_HEADERS)
IMAGE_FILE_HEADER
IMAGE_OPTIONAL_HEADER32
IMAGE_DATA_DIRECTORY16
IMAGE_SECTION_HEADER0
Sections Information
IMAGE_SECTION_HEADERn
SECTION0
SECTIONn


86
Using Ordinal Numbers to Identify DLL Procedures

• In addition to a name, all DLL procedures can be
  identified by an ordinal number that specifies
  the procedure in the DLL.
• Some DLLs do not include the names of their
  procedures and require you to use ordinal numbers
  when declaring the procedures they contain.

87
MS-DOS Information
value
offset
e_lfanew is the offset which refers to the
position of the Windows NT data.
88
Structure IMAGE_NT_HEADERS

• typedef struct _IMAGE_NT_HEADERS
• DWORD Signature
• IMAGE_FILE_HEADER FileHeader
• IMAGE_OPTIONAL_HEADER OptionalHeader
• IMAGE_NT_HEADERS, PIMAGE_NT_HEADERS1

89
Access the MS-DOS header and the Windows NT Header

• If you assume that the pMem pointer relates the
  start point of the memory space for a selected
  portable executable file, you can retrieve the
  MS-DOS header and also the Windows NT header by
  the following lines,
• IMAGE_DOS_HEADER image_dos_header
• IMAGE_NT_HEADERS image_nt_headers
• PCHAR pMem
• ...
• memcpy(image_dos_header, pMem,
  sizeof(IMAGE_DOS_HEADER))
• memcpy(image_nt_headers, pMemimage_dos_heade
  r.e_lfanew,
• sizeof(IMAGE_NT_HEADERS))

90
Signature and IMAGE_FILE_HEADER of Windows NT
Information
91
Structure IMAGE_OPTIONAL_HEADER

• typedef struct _IMAGE_OPTIONAL_HEADER
• WORD Magic
• BYTE MajorLinkerVersion
• BYTE MinorLinkerVersion
• DWORD SizeOfCode
• DWORD SizeOfInitializedData
• DWORD AddressOfEntryPoint
• DWORD ImageBase
• DWORD SizeOfStackReserve
• DWORD SizeOfStackCommit
• DWORD SizeOfHeapReserve
• DWORD SizeOfHeapCommit
• DWORD LoaderFlags
• DWORD NumberOfRvaAndSizes
• IMAGE_DATA_DIRECTORY DataDirectoryIMAGE_NUMBEROF
  _DIRECTORY_ENTRIES
• IMAGE_OPTIONAL_HEADER,PIMAGE_OPTIONAL_HEADER

A pointer to the first IMAGE_DATA_DIRECTORY
structure in the data directory.
92
AddressOfEntryPoint and ImageBase

• AddressOfEntryPoint
• A pointer to the entry point function, relative
  to the image base address.
• ImageBase
• The preferred address of the first byte of the
  image when it is loaded in memory.
• This value is a multiple of 64K bytes.
• The default value for DLLs is 0x10000000.
• The default value for applications is 0x00400000.

93
Remarks

• The actual structure in Winnt.h is named
  IMAGE_OPTIONAL_HEADER32 and IMAGE_OPTIONAL_HEADER
  is defined as IMAGE_OPTIONAL_HEADER32.
• However, if _WIN64 is defined, then
  IMAGE_OPTIONAL_HEADER is defined as
  IMAGE_OPTIONAL_HEADER64.

94
IMAGE_OPTIONAL_HEADER32 of Windows NT Information
95
IMAGE_DATA_DIRECTORY

• Represents the data directory.
• typedef struct _IMAGE_DATA_DIRECTORY
• DWORD VirtualAddress DWORD Size
• IMAGE_DATA_DIRECTORY, PIMAGE_DATA_DIRECT
  ORY
• Members
• VirtualAddress
• The relative virtual address of the table.
• Size
• The size of the table, in bytes.

points to a IMAGE_IMPORT_DESCRIPTOR structure
96
List of the Data Directories
97
IMAGE_DATA_DIRECTORY of Windows NT Information
points to a IMAGE_IMPORT_DESCRIPTOR
structure. Each DLL file has a corresponding
IMAGE_IMPORT_DESCRIPTOR structure.
type
98
IMAGE_DATA_DIRECTORY and IMAGE_IMPORT_DESCRIPTOR
import table
IMAGE_IMPORT_DESCRIPTOR IMAGE_IMPORT_DESCRIPTOR

99
Example stinson

• If we have a PE that imports two modules, we'll
  have
• one IMAGE_DATA_DIRECTORY structure for the Import
  Symbols (i.e. the Import Table)
• let's say that struct's VirtualAddress is 0xc7d8
  -- recall this is an RVA.
• then 0xc7d8 is where the first IMAGE_IMPORT_DESCRI
  PTOR lives
• since we are importing two modules, there will be
  3 IMAGE_IMPORT_DESCRIPTOR structs in our array
  (which starts at 0xc7d8, recall)
• --gt the 3rd IMAGE_IMPORT_DESCRIPTOR is all zeroes
  
• then the Size field above (for this
  IMAGE_DATA_DIRECTORY) will be 3 sizeof(
  IMAGE_IMPORT_DESCRIPTOR )

100

• IMAGE_SECTION_HEADER

101
IMAGE_SECTION_HEADER

• Represents the image section header format.
• typedef struct _IMAGE_SECTION_HEADER
• BYTE NameIMAGE_SIZEOF_SHORT_NAME
  union
• DWORD PhysicalAddress DWORD
  VirtualSize Misc DWORD
  VirtualAddress DWORD SizeOfRawData
  DWORD PointerToRawData DWORD
  PointerToRelocations DWORD
  PointerToLinenumbers WORD
  NumberOfRelocations WORD NumberOfLinenumbers
  DWORD Characteristics
• IMAGE_SECTION_HEADER,
  PIMAGE_SECTION_HEADER

The address of the first byte of the section when
loaded into memory, relative to the image base.
102
Section Names
103
IMAGE_SECTION_HEADER Array of Section Information
104
SECTION Array of Section Information
105
Import Address Table

• Within a PE file, there's an array of data
  structures, one per imported DLL.
• Each of these structures gives
• the name of the imported DLL
• points to an array of function pointers
• The array of function pointers is known as the
  import address table (IAT).
• Each imported API has its own reserved spot in
  the IAT where the address of the imported
  function is written by the Windows loader.
• Once a module is loaded, the IAT contains the
  address that is invoked when calling imported
  APIs.

106
Imported API Calls and the IAT

• The beauty of the IAT is that there's just one
  place in a PE file where an imported API's
  address is stored. No matter how many source
  files you scatter calls to a given API through,
  all the calls go through the same function
  pointer in the IAT.
• Let's examine what the call to an imported API
  looks like.
• CALL 0x0040100C
• CALL 0x0040100C
• 0x0040100C
• JMP DWORD PTR 0x00405030
• Here, 0x405030 is an entry within the IAT.

stub code
107
Stub Code

• The CALL in previous slide transfers control to a
  small stub. The stub is a JMP to the address
  whose value is at 0x405030.

108

• The Imports Section Matt PietrekIczelion

109
Section .idata

• Section .idata contains information about Import
  Address Table.
• This part of the PE structure is particularly
  very crucial for building a spy program based on
  altering IAT.

110
Location of Section .idata in a PE File
111
IMAGE_IMPORT_DESCRIPTOR Structure

• The anchor of the imports data is the
  IMAGE_IMPORT_DESCRIPTOR structure.
• There's one IMAGE_IMPORT_DESCRIPTOR for each
  imported executable (e.g. DLL file).
• The end of the IMAGE_IMPORT_DESCRIPTOR array is
  indicated by an entry with fields all set to 0.

112
Structure IMAGE_IMPORT_DESCRIPTOR

• typedef struct _IMAGE_IMPORT_DESCRIPTOR
• DWORD OriginalFirstThunk
• DWORD TimeDateStamp
• DWORD ForwarderChain
• DWORD Name
• DWORD FirstThunk
• IMAGE_IMPORT_DESCRIPTOR, PIMAGE_IMPORT_DESCRIPT
  OR

113
Members of Structure IMAGE_IMPORT_DESCRIPTOR
114
An Executable Importing Some APIs from USER32.DLL
IMAGE_THUNK_DATA

• An IMAGE_IMPORT_DESCRIPTOR element has elements
  with a RVA value to a type IMAGE_THUNK_DATA,
  which is a pointer-sized union.
• Each IMAGE_THUNK_DATA element corresponds to one
  imported function from the executable. The ends
  of IMAGE_THUNK_DATA arrays are indicated by an
  IMAGE_THUNK_DATA element with a value of zero.

115
Structure IMAGE_THUNK_DATA

• typedef struct _IMAGE_IMPORT_BY_NAME
• WORD Hint
• BYTE Name1
• IMAGE_IMPORT_BY_NAME, PIMAGE_IMPORT_BY_NAME
• typedef struct _IMAGE_THUNK_DATA
• union
• PDWORD Function
• PIMAGE_IMPORT_BY_NAME AddressOfData
• u1
• IMAGE_THUNK_DATA, PIMAGE_THUNK_DATA

116
Interpretation of Fields of Structure
IMAGE_THUNK_DATA

• The IMAGE_THUNK_DATA union is a DWORD with these
  interpretations
• DWORD Function // Memory address of the
  imported function
• DWORD Ordinal // Ordinal value of
  imported API
• DWORD AddressOfData // RVA to an
  IMAGE_IMPORT_BY_NAME with
• // the imported API name
• DWORD ForwarderString // RVA to a forwarder
  string

117
IMAGE_THUNK_DATA Structures of the IAT

• The IMAGE_THUNK_DATA structures within the IAT
  lead a dual-purpose life.
• In the executable file, they contain
• either the ordinal of the imported API
• or an RVA to an IMAGE_IMPORT_BY_NAME structure.
• The IMAGE_IMPORT_BY_NAME structure is just a
  WORD, followed by a string naming the imported
  API.
• The WORD value is a hint to the loader as to what
  the ordinal of the imported API might be.
• When the loader brings in the executable, it
  overwrites each IAT entry with the actual address
  of the imported function.

118
Binding

• When an executable is bound (via the bind
  program, for instance), the IMAGE_THUNK_DATA
  structures in the IAT are overwritten with the
  actual address of the imported function.
• The executable file on disk has the actual
  in-memory addresses of APIs in other DLLs in its
  IAT.
• When loading a bound executable, the Windows
  loader can bypass the step of looking up each
  imported API and writing it to the IAT. The
  correct address is already there.

119
Spying by Altering of the Import Address Table

• Here are the logical steps of a replacing cycle
• Find the IMAGE_IMPORT_DESCRIPTOR chunk of the DLL
  that exports that function.
• Practically speaking, usually we search this
  entry by the name of the DLL
• Locate the IMAGE_THUNK_DATA which holds the
  original address of the imported function
• Replace the function address with the one
  supplied by users
• By changing the address of the imported function
  inside the IAT, we ensure that all calls to the
  hooked function will be re-routed to the function
  interceptor.

120

• Case Study 1

121
A Simple Rootkit

• A simple script put in Perls string context,
  compiled and named netstat.exe may be an example
  of a trivial rootkit.
• A real system netstat could be named
  oldnetstat.exe. The principle of operation of the
  new netstat is that
• once the command line calls the real netstat (now
  oldnetstat.exe), its results will be directed to
  a temporary text file.
• Then the rootkit searches that file for any
  information about the listening port to remove it
  (according to the procedure predefined in the
  rootkit code).
• After modification, the result is displayed on
  the screen and the old file is removed.
• This principle is both simple and efficient and
  provides an interesting possibility it may be
  used to spoof output data acting from any other
  tool available through the command line for
  example, tlist, or dir.
• There are many programs of this type available on
  the Web.
• Some of them did not display, for example,
  information on listening ports such as 666,
  27374, 12345, 31337 i.e. well-known Trojan
  horse ports.

122

• Case Study 2

123
A Windows Rootkit Example -- Rootki

• The idea of a first enhanced rootkit, Rootki, for
  the Windows environment was born in due time.
• The originator was Greg Hoglund.

124
Rootki 0.40 Existing Form and Activating Methods

• This rootkit has been designed as a kernel mode
  driver that runs with system privileges right at
  the core of the system kernel.
• Given this fact, it has access to all resources
  of the operating system, thus having a broad
  field of action.
• In order to install it one requires the
  administrators permissions whilst simple net
  start/net stop commands are sufficient to
  activate/disactivate it respectively.

125
Rootki 0.40 Hiding Approach

• Once the rootkit has been loaded, the hacker can
  hide directories and files on the victims disk.
• This method is efficient provided that the object
  to be hidden has a name prefixed with _root_
  for example, _root_directory_name.
• How does this work?
• The rootkit, by patching the kernel,
• intercepts all system calls for the listing of
  the disk content
• and
• all objects beginning with the sequence _root_
  are hidden from display.
• The same applies to the searching process all
  files and directories with the above sequence of
  characters are hidden from the search.

126
Rootki 0.40 Hiding Processes

• This rootkit feature can also be used
• to hide processes running
• as well as
• to do the same with the system registry entries,
  by prefixing all keys and entries with _root_
  .
• This enables the hacker to install, for example,
  services which will become a backdoor, thus being
  as invisible for the system administrator as
• services or
• registry entries or
• processes running in the system memory.

127
Rootki 0.40 Key Logger

• The rootkit can also intercept all key strokes
  typed at the system console.
• This may be carried out by hooking into the
  keyboard driver and issuing the sniffkeys
  command.

128

• Case Study 3

129
A Famous Rootkit Case

• The word "rootkit" came to public awareness in
  the 2005 Sony CD copy protection scandal, in
  which Sony BMG music CDs surreptitiously placed a
  rootkit on Microsoft Windows PCs when the CD was
  played on the computer.
• Sony provided no mention of this in the CD or its
  packaging, referring only to security rights
  management measures.

130

• Protect Systems against Rootkits

131
Guarding against the Rootkit Checking from
Other Hosts

• vulnerability of a rootkit objects are only
  hidden from the environment of the compromised
  machine and they can easily be seen from another
  computer.
• Mapping a Network Drive remotely from another
  machine (or using net use command) is a means to
  see everything, which has been hidden for a local
  user.
• This is because the remote machine is using a
  clean kernel to view the files and directories on
  the compromised machine, avoiding the rootkits
  filtration process.

132
Guarding against the Rootkit Renaming Check
Utilities

• A rootkit, however, cannot affect processes that
  have _root_ in their names.
• In other words, when a system administrator, is
  analyzing the system log using regedit.exe, he
  cannot see hidden entries, but just by changing
  its name to  _root_regedit.exe, it will be enough
  for him to see all of them as well as hidden keys
  and registry entries. This is true for all
  programs for example, Task Manager.

133

• Appendix (could be omitted)

134
List the Names of ALL Import Functions of a PE
File (1) Iczelion

• Verify that the file is a valid PE
• From the DOS header, go to the PE header
• Obtain the address of the data directory in
  OptionalHeader
• Go to the 2nd member of the data directory.
  Extract the value of VirtualAddress
• Use that value to go to the first
  IMAGE_IMPORT_DESCRIPTOR structure
• Check the value of OriginalFirstThunk. If it's
  not zero, follow the RVA in OriginalFirstThunk to
  the RVA array. If OriginalFirstThunk is zero, use
  the value in FirstThunk instead. Some linkers
  generate PE files with 0 in OriginalFirstThunk.
  This is considered a bug. Just to be on the safe
  side, we check the value in OriginalFirstThunk
  first.

135
List the Names of ALL Import Functions of a PE
File (2) Iczelion

• For each member in the array, we check the value
  of the member against IMAGE_ORDINAL_FLAG32. If
  the most significant bit of the member is 1, then
  the function is exported by ordinal and we can
  extract the ordinal number from the low word of
  the member.
• If the most significant bit of the member is 0,
  use the value in the member as the RVA into the
  IMAGE_IMPORT_BY_NAME, skip Hint, and you're at
  the name of the function.
• Skip to the next array member, and retrieve the
  names until the end of the array is reached (it's
  null -terminated). Now we are done extracting the
  names of the functions imported from a DLL. We go
  to the next DLL.
• Skip to the next IMAGE_IMPORT_DESCRIPTOR and
  process it. Do that until the end of the array is
  reached (IMAGE_IMPORT_DESCRIPTOR array is
  terminated by a member with all zeroes in its
  fields).