kasslin AVAR2006 KernelMalware paper

Embed Size (px)

Citation preview

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    1/15

    Abstract

    Te Kernel is the heart o modern operating systems. Code executing in kernel mode has ull access to all memory includingthe kernel itsel, all CPU instructions, and all hardware. For this obious reason only the most trusted soware should beallowed to run in kernel mode.

    oday, we are acing an emerging threat in the orm o kernel-mode malware. By kernel-mode malware we mean mali-cious soware that executes as part o the operating system haing ull access to the computers resources. o the end-userthis means malware that can bypass soware rewalls and can be almost impossible to detect or remove een i the bestanti-irus solutions are being used.

    Tis paper will examine the most important malware cases utilizing kernel-mode techniques oer the last ew years. Te re-search will be limited to malware running on Windows N and later operating system ersions. It will look at the possiblemoties or the malware authors to move their creations to kernel mode. A detailed analysis o the key techniques makingtheir existence possible will be covered.

    Kenel le e A nle e A n e A n

    Kimmo KasslinF-Secure

    Kuala LumpurMalaysia

    [email protected]

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    2/15AVAR 2006 - AucklAnd

    Indun

    A modern malware, backdoor, email-worm, spying tro-jan, operating ully in kernel mode on a Windows N-based operating system is a scary thought. It would oper-ate with same privileges and share all the same resourcesas the operating system itsel and compete with any se-curity solutions protecting the systems integrity againstany malicious activities. Tis would end up in an armsrace between the malware and the security suite. Te onethat is able to execute rst or being able to control thelowest parts o the operating system eventually will bethe winner. Usually, this means doing tricks that are notdocumented or supported by Microso and will result in version dependencies causing instability or even systemcrashes in the worst case. Tis is a path any serious secu-rity soware vendor will not take. However, the world is

    ull o examples o malware and proo-o-concept codethat does exactly this.

    Tis paper is about malware operating ully or partially inkernel mode. It will discuss basic requirements or suchmalware and survey the known and semi-documentedtechniques that make it possible or malware writers toenter into and operate in ring 0. Te paper ends with ana-lyzing two sample cases o malware that have played animportant role in opening eyes o the security community

    to the threat kernel malware poses.

    B Defnn

    o have a better understanding o the topic the readershould be amiliar with some basic concepts o a modernoperating system. erms such as processes, threads, vir-tual memory and the dierence between user and kernelmodes should be amiliar to the reader. Te most impor-tant concepts, including important denitions to avoid

    misunderstandings are introduced here.

    kere Moe vs. user Moe

    One o the design goals or Windows N was reliabilityand robustness [34]. Te main requirement was to protectthe kernel rom external tampering by user-mode applica-tions. o address this, the system was divided into two di-erent modes o operation: user mode and kernel mode.User applications run in user mode. Tey are unprivilegedprocesses with limited access to system resources. User-

    mode processes access these resources controlled by thekernel through services provided by the kernel.

    Operating system services and third party drivers runin kernel mode. In kernel mode, they have access to all

    system memory, all CPU instructions, and all hardware.Te architecture o the Intel x86 processor supports ourprivilege levels, or rings, numbered rom 0 to 3. Te great-er numbers mean lesser privileges. Windows uses privi-lege level 0 or kernel mode and privilege level 3 or usermode.

    o provide protection to the virtual memory, the OSkeeps track rom which privilege level each memory pagecan be accessed. Pages in system address space can be onlyaccessed rom kernel mode, which protects them romuser-mode processes. Since code running in kernel modehas ull access to system memory, it can easily bypass anysecurity mechanism provided by the OS and destroy itsintegrity.

    Drivers run in kernel mode and third party drivers can beinstalled and loaded with administrative privileges. Tis

    is the only documented and supported way o executingkernel-mode code. Other undocumented means do existand they are explained in more detail in a later section

    For detailed inormation about the inner workings oWindows N-based operating systems the author recom-mends the excellent book by Solomon and Russinovich[34].

    kere Maware

    Kernel malware is malicious soware that runs ully or partially at the most privileged execution level, ring 0,having ull access to memory, all CPU instructions, andall hardware. It is convenient to divide kernel malwareinto two subcategories: ull-kernel malware and semi-ker-nel malware.

    Full-Kernel Malware

    Full-Kernel malware is ully implemented as kernel-modedriver and executes all its code in ring 0. It still requiressome help rom user mode to get installed into the systemeither by a dropper component or manually by the user.Once the driver has been installed it will be able to oper-ate by itsel.

    Semi-Kernel Malware

    Semi-Kernel malware executes its code both in ring 0and 3. Tis includes malware that consists o a user-modeexecutable (EXE or DLL) that will drop a kernel-modedriver or use other means to execute code in ring 0. Mal-ware that is ully implemented as kernel-mode driver butexecutes parts o its payload in ring 3, e.g. through codeinjection, in the context o some process is also semi-ker-nel malware.

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    3/15AVAR 2006 - AucklAnd

    Hy nd Tend Kenel le

    Kernel-mode malware on Windows N-based systemsis not a new phenomenon, they have just been rare.WinN/Ins [24], which was discovered in November1999, was the rst known ull-kernel malware that wasdesigned to run on N-based systems. It was a memory-resident parasitic kernel-mode driver virus that gainedcontrol by hooking the IN 0x2E interrupt handlerdirectly rom kernel. Tis allowed it to monitor everysystem service call made by user-mode applications andto inect PE EXE les when an open request was made. Win2K/Ins.4608 [35] added support or Windows2000 and was ound just one week aer the new operat-ing system was released.

    Another documented case involving kernel-mode mal-

    ware was Virus.Win32.Chatter1

    [2][36], which wasound in January 2003. It was a kernel-mode driver thatinects only PE SYS les. It hooks nt!NtCreateFile romnt!KiServiceTable and thus gets control on every le openand create operation. However, its inection routine wasactually executed in user mode. Tereore it is a semi-kernel malware. Te driver copied itsel into the addressspace o the active process and used an undocumentednt!KeUserModeCallBack unction exported by the kernelto execute the inection routine in user mode. Tis might

    have been the rst time or kernel malware to inject partso its payload rom ring 0 to ring 3 to perorm some morecomplex tasks. Tis code injection rom kernel to usermode is an important concept and will be discussed inmore detail later in this paper.

    oday the number o kernel-mode malware when com-pared to the total number o malware seen every month isvery small. Also, it should be noted that the antivirus in-dustry has not yet seen any complex malware that wouldulll the requirements or ull-kernel malware. o get a

    better view o how real the threat posed by kernel mal-ware is, it is important to nd some evidence o real-liemalware samples using kernel-mode components.

    Antivirus analysts who have been analyzing malwaresamples since the beginning o 2005 should agree thatthe number o malware using kernel components hasbeen steadily increasing. o get more proo o this trenda statistical analysis was conducted. Te author chose twoantivirus vendors and processed all monthly sample col-

    lections rom January 2003 to August 2006. On averagethis resulted in around 100000 samples per vendor. Teidea was to nd out how many kernel-mode drivers the

    1. Also know as W32.Keck.1933 (Symantec) and W32/ChatterAlso know as W32.Keck.1933 (Symantec) and W32/ChatterAlso know as W32.Keck.1933 (Symantec) and W32/Chatter(McAee).

    sample collections had, meaning that they are either ull-kernel malware or parts o semi-kernel malware. In addi-tion, the number o new malware amilies that use kernel-mode drivers was identied. It is important to notice that just looking or drivers will not include kernel malwarethat use other means, like code injection or call gates, toexecute their code in ring 0. However, this would require

    run-time analysis o the samples, which was not possibleto achieve within the given time rame.

    Each sample in the monthly collection was rst checkedwhether it had a proper PE header. I the result was posi-tive then additional tests were made against the optionalheader eld. Following basic checks were made to includeonly samples that are possibly kernel-mode drivers orWindows N and later operating system versions:

    Magic eld equals IMAGE _ NT _ OPTION-

    AL _ HDR32 _ MAGIC

    Subsystem eld equals IMAGE _ SUBSYS-TEM _ NATIVE

    MajorSubsystemVersionandMinorSub-systemVersion elds were checked against thecorrect platorm and version inormation

    In addition all duplicate les were removed by checkingtheir MD5 hash. Te results are shown in Figure 1 be-

    low.

    0

    10

    20

    30

    40

    50

    60

    70

    80

    Jan-03

    Apr-0

    3Jul-03

    Oct

    -03

    Jan-04

    Apr-0

    4Jul-04

    Oct

    -04

    Jan-05

    Apr-05Jul-05

    Oct

    -05

    Jan-06

    Apr-0

    6Jul-06

    No.samples

    0

    1

    2

    3

    4

    5

    6

    No.new

    families

    M al wa re F am i li es V en do r X V en do r Y

    Figure 1. Number o malicious kernel-mode drier samplesound fom each endor collection per month. Also, in-cludes the number o new malware amilies ound to usekernel-mode components.

    Beore discussing more about the results it should benoted that there exists possible actors o uncertainty to-wards the validity o the results. Tis is mostly related tothe quality o the data these results are based on. Te au-thor is not trying to imply that there is anything wrong with the collections, it is just a known problem in theantivirus industry that proper classication and naming

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    4/15AVAR 2006 - AucklAnd

    o malware is impossible with the amount o samples theindustry have to handle every day.

    Also, normally drivers are embedded inside the mainmalware component and will be dropped to the systemwhen the main component is executed. However, quiteoen the dropped driver is named by its characteristics,e.g. Hacktool.Rootkit2, not by the malware using it. Fromthe end-users point-o-view this is a good thing but itmakes it very dicult or researchers to make any conclu-sions how many dierent amilies are using kernel-modecomponents without actually executing every sample andchecking what kind o components they are dropping tothe system.

    Despite all the uncertainty the author eels condentto make a conclusion based on the achieved results thatnumber o kernel-mode malware has steadily increased

    during the investigated time period. Tis is very evidentrom year 2005 onwards, which is mostly explained bythe increased number o malware starting to use kernel-mode rootkits to hide their presence on the compromisedsystem. Tere is a noticeable dierence in the number osamples rom 2005 onwards between the two vendors. Invendor Ys case the curve is more stable where the amounto driver samples has approximately tripled every year.Te raw number o new samples per month is not thatinteresting since these samples contain lots o variants o

    the same amily. Probably more interesting inormationis the number o new malware amilies that were identi-ed to be using kernel-mode drivers. Tis gives a betterpicture o the kernel malware trend.

    During year 2003 an average o 0.67 new malware ami-lies per month were identied to utilize kernel-mode driv-ers. Year 2004 was still quite calm when an average o onenew amily per month was identied. Te trend changeddramatically during year 2005 when an average o 3.42new kernel malware amilies was ound. Since then things

    have calmed down a bit but the usage o kernel malware isstill growing strongly with an average o 2.63 new amiliesound each month. able 1 contains the list o most activeamilies based on the number o new variants seen.

    able 1. Most commonly used kernel-mode malware.F-Seue Syne Aee

    Backdoor.Win32.Haxdoor Backdoor.Haxdoor Backdoor-BAC

    Backdoor.Win32.HacDe Backdoor.HackDeender HackerDeender trojan

    rojan-Spy.Win32.Banker Inostealer.Bancos PWS-Banker trojan

    Backdoor.Win32.PcClient Backdoor.Formador BackDoor-CKB trojan

    rojan- Spy.Win32.Goldun rojan.Goldun PWS-Goldun trojan

    rojan .Win32.Cr ypt.t Spyware.Apropos.C Adware-Apropos

    Spamool.Win32.Mailbot Backdoor.Rustock.A Spam-Mailbot trojan

    2. Tis is a generic detection name used by Symantec or rootkits.

    rojan-Clicker.Win32.Costrat Backdoor.Rustock.B Spam-Mailbot.c trojan

    Other important amilies worth to mention that havebeen seen to utilize kernel-mode code are Email-Worm. Win32.Bagle and Mydoom-based Email-Worm.Win32.Gurong [10]. In addition usage o kernel-mode rootkitdrivers has been very common in IRC bots such as Back-

    door.Win32.SdBot and Backdoor.Win32.Rbot.Te high rise in popularity o kernel malware can bemostly explained by the increased motivation or malwareauthors to hide their creations rom detection as longas possible. o hide even better they have started to usekernel-mode rootkit techniques as more and more doc-umentation, examples and ully working examples withull source code has become publicly available. However,there are other motives or malware to move to kernel,probably most important ones being rewall and antivi-

    rus scanner bypassing.

    Key Tenque Ued y Kenel le

    One reason why kernel malware has been so rare is thatdeveloping kernel-mode drivers is not easy. Te environ-ment limits the developers creativity since it oers only alimited number o exported library unctions, documen-tation is limited and there is less examples and source codeavailable that can be used as a template or the maliciouswork. oday the situation is changing. More inormationis published about how to do things required by todaysmalware directly rom kernel mode. Tis includes how toimplement better rootkits, how to bypass personal re-walls and how to create backdoors and IRC bots.

    o better understand the threat o kernel malware it is im-portant to know how they work. Tis chapter tries to givea brie introduction on the key techniques that are usedby kernel malware.

    Exetig coe i Rig 0

    Te rst requirement or a malware trying to obtain thepowers o kernel malware is to execute its code in the mostprivileged level ring 0. Te author has seen malware us-ing two dierent techniques to achieve this, kernel-modedrivers and call gates.

    Kernel-Mode Drivers

    Te only documented way to execute third party kernel-

    mode code is to install a kernel-mode driver. Tey areloadable kernel-mode modules, usually having extension.sys, and execute in one o three contexts:

    In the context o user-mode thread that initiated an

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    5/15AVAR 2006 - AucklAnd

    I/O handler unction

    In the context o kernel-mode system thread

    In the context o random thread as a result o aninterrupt

    Structurally they are identical to any other PE le. Kernel-

    mode drivers can use support routines that are exportedby various components o the OS kernel. Tese routinessupport I/O, conguration, Plug and Play, power man-agement, memory management, and numerous other OSeatures. [34]

    ypically, drivers are loaded and started at OS boot time.However, Windows API provides necessary unctionsthat allow loading and unloading drivers at run time. Tisis done by the Service Control Manager (SCM). A new

    driver can be installed with the CreateService API unc-tion. Tis unction has the ollowing syntax [37]:

    SC _ HANDLECreateService(

    SC _ HANDLE hSCManager,LPCTSTR lpServiceName,LPCTSTR lpDisplayName,DWORD dwDesiredAccess,DWORD dwServiceType,DWORD dwStartType,DWORD dwErrorControl,LPCTSTR lpBinaryPathName,LPCTSTR lpLoadOrderGroup,LPDWORD lpdwTagId,LPCTSTR lpDependencies,LPCTSTR lpServiceStartName,LPCTSTR lpPassword

    );

    Here, the important parameters are hSCManager,dwServiceType, dwStartType, and lpBina-ryPathName. Te hSCManager parameter is a han-dle to the SCM database, which can be obtained with the

    OpenSCManager API unction. Te dwService-Type parameter species the type o the service that willbe installed. In this case, it must have the value oSER-VICE _ KERNEL _ DRIVER. Te dwStartTypeparameter denes the startup behavior o the driver whenthe system boots up. Te nal parameter o interest is thelpBinaryPathName, which is a pointer to a null-ter-minated string that contains the ully qualied path tothe driver binary le. [37]

    A successul call to the CreateServiceAPI unctioncreates a service object, returns a handle to this object,and installs the service in the SCM database by creating akey with the same name as the service under the ollowingregistry key:

    HKEY _ LOCAL _ MACHINE\System\Current-

    ControlSet\Services

    Te driver can be started by passing the service objecthandle to the StartService API unction. Tiscauses the system to perorm some actions that are simi-lar to loading a normal user-mode DLL. An image o thedrivers PE le is loaded into system address space and theentry point o the driver is called. Te entry point is alsoknown as the DriverEntry, which has ollowing pro-totype [22]:

    NTSTATUSDriverEntry(

    IN PDRIVER _ OBJECT DriverObject,IN PUNICODE _ STRING RegistryPath

    );

    DriverEntry routine always runs in the context othe system thread. Tis routine is called only once dur-ing the lietime o the driver and its only purpose is toinitialize the driver. However, this is all that is requiredor the malware to execute its payload, which quite oeninvolves hooking kernel unctions or installing additionalnotication unctions or system threads to perorm anyurther work. [22]

    Tere exists another way to load and execute a kernel-

    mode driver rom user mode.Tis method is not documented by Microso in any way.Te existence o this method was announced by Hoglund[38] in his post to the Bugraq mailing list.

    More recent inormation can be ound in the book writ-ten by Hoglund and Butler [15]. Tis method uses theZwSetSystemInformation unction exported byNtdll.dll and has the ollowing syntax [23]:

    NTSYSAPINTSTATUSNTAPIZwSetSystemInformation(

    IN SYSTEM _ INFORMATION _ CLASSSystemInformationClass,

    IN OUT PVOID SystemInformation,IN ULONG SystemInformationLength

    );

    Te SystemInformationClass parameter speci-es the type o system inormation to be set. In this caseit is set to value o SystemLoadAndCallImage, which is part o the SYSTEM _ INFORMATION _CLASS enumeration. TeSystemInformation pa-rameter points to the data will be set. In this case, it will be

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    6/15AVAR 2006 - AucklAnd

    dened as a structure that has the ollowing syntax [23]:

    typedef struct _ SYSTEM _ LOAD _ AND _ CALL _IMAGE {UNICODE _ STRING ModuleName;} SYSTEM _ LOAD _ AND _ CALL _ IMAGE, *PSYS-TEM _ LOAD _ AND _ CALL _ IMAGE;

    Te ModuleName element species the ull path o themodule that will be loaded in Unicode ormat. Te lastparameter o the ntdll!ZwSetSystemInformation unction species the size in bytes o the data pointedby the SystemInformation parameter. Aer a suc-cessul unction call, the system loads the module into thesystem address space and calls its entry point. Tis tech-nique has both good and bad eatures.

    Te upside or malware is that it leaves no inormationinto the SCM database. Tis method provides malware a

    way to load and execute a kernel-mode driver in a singleoperation without leaving any traces o its existence in theregistry. Because the SCM is not aware o the driver, itis not able to control it in any way. Te driver cannot beunloaded and it will survive in memory until the next re-boot.

    Te downside or malware is that the driver will not bestarted aer the system has been rebooted. Another prob-lem is that memory or the driver image will be allocated

    rom the paged pool, which restricts the kind o opera-tions the driver can execute. Otherwise it risks o crashingthe system with a blue screen. Tere are ways to avoid thisproblem but it will make the driver code more complexand harder to maintain [15].

    As expected, the documented way is the one used by mostmalware to execute code in kernel mode. I it works, thereis no reason or malware to search or alternate means.Tis might change in the uture when more security prod-ucts start to block loading o kernel-mode drivers.

    Call Gates

    Call gates are a less known technique to execute thirdparty kernel-mode code. Tey are provided by the Intelarchitecture and can be used to transer program con-trol between dierent privilege levels. Call gates reside inthe system address space. A user-mode process has to beable to modiy it to add its own call gate. Tis is possiblethrough two undocumented Windows OS eatures that

    are discussed next.

    Te rst method was rst discovered by Mark Russino- vich [32] and it was urther documented by Crazylord[3]. It uses a section object named \Device\Physi-

    calMemory, which allows a user-mode application tomap portions o the physical memory into its own addressspace. Tis technique is known to malware and has beenused beore by some malware variants to hide themselvesusing rootkit techniques [21]. Tis technique has itsproblems since it accesses physical memory. Te malwareneeds to calculate virtual to physical address translation

    correctly. Email-Worm.Win32.Fanbot.j3

    was the rst onethat did the translation properly and thereore had bettersupport or dierent OS versions [4].

    Te second method to access the system address spacerom user mode is more useul because it uses virtual ad-dresses instead o physical addresses. Tis method usestheZwSystemDebugControl unction exported byNtdll.dll and has the ollowing syntax [23]:

    NTSYSAPINTSTATUSNTAPIZwSystemDebugControl(

    IN DEBUG _ CONTROL _ CODE ControlCode,IN PVOID InputBuffer OPTIONAL,IN ULONG InputBufferLength,OUT PVOID OutputBuffer OPTIONAL,IN ULONG OutputBufferLength,OUT PULONG ReturnLength OPTIONAL

    );

    o use this unction the caller is required to have the

    SeDebugPrivilege enabled. Te important eldhere is the ControlCode, which denes the mode ooperation. Valid values are dened in theDEBUG _ CON-TROL _ CODE enumeration. However, this enumerationhas not been documented since Windows 2000.

    Randnuts [26] post to the Bugtraq mailing list showedthat new eatures were added to the ntdll!ZwSystemDebugControl unction on Windows XP and 2003.Te essential inormation was posted to a public discus-sion orum by a person known as Bilbo. He claimed that

    it was possible to write to the system address space by set-ting the ControlCode parameter to the value o nine.He also posted the ollowing example code:

    /** write a buffer to kernel space*/struct {LPVOID kernel _ addr;LPVOID user _ addr;

    DWORD len;} mem;

    voidwr(LPVOID dst, LPVOID src, DWORD len)

    3. Also known as W32.Fanbot.Amm (Symanted) and W32/My-Also known as W32.Fanbot.Amm (Symanted) and W32/My-Also known as W32.Fanbot.Amm (Symanted) and W32/My-tob.genMM (McAee).

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    7/15AVAR 2006 - AucklAnd

    {mem.kernel _ addr = dst;mem.user _ addr = src;mem.len = len;

    ZwSystemDebugControl(9, &mem,sizeof(mem), 0, 0, 0);

    }

    Tis made it possible or easy access to kernel-mode mem-ory without any need to or complex address translationcalculations. Lately, ntdll!ZwSystemDebugControl unction was documented in much detail by AlexIonescu [20]. Tis might result in more malware usingthis approach to enter the kernel. So ar the author hasnot encountered any malware samples that had used thistechnique.

    Microso has realized the potential problem these un-documented backdoors to the system address space pose

    to the overall security o their operating systems. SinceWindows Server 2003 SP1 they can no longer be calledrom user mode [20].

    Now that we know the techniques to install the call gaterom ring 3 it is time to see how they actually work. Callgates are based on the same techniques the OS uses whenit executes kernel-mode code on behal o the user-modeapplication. At the lowest level, this separation o privi-lege levels is implemented by the protection mechanismprovided by the Intel processors, also known as protectedmode o operation. Te reader is assumed to be amiliarwith concepts such as memory segmentation and privi-lege levels. For more inormation, the reader is advised toreer to the Intel manuals [16][17][18][19].

    o provide a controlled way to transer program controlbetween dierent privilege levels the Intel architectureprovides a acility called call gates. A call gate is denedby a call-gate descriptor, which may reside in the GlobalDescriptor able (GD) or in a Local Descriptor able

    (LD).Figure 2 shows the ormat o a call-gate descrip-tor.

    Figure 2. Call-gate descriptor Source: [19]

    Te Segment Selector eld in a call gate speci-es the code segment to be accessed. Te Offset eldspecies the entry point in the code segment. Generally,

    it points to the rst instruction o a specic procedure.Te Descriptor Privilege Level (DPL) eldindicates the privilege level required to access the selectedprocedure through the gate. Te Parameter Counteld indicates the number o parameters to copy rom thecalling procedures stack to the new stack i a stack switchoccurs.

    A call gate is used by speciying a ar pointer to the gateas the target operand in a CALL or JMP instruction. Tepointer consists o a segment selector and an oset. Tesegment selector identies the call gate and the oset isrequired, but not used. When the processor has accessedthe call gate and the privilege checks has been success-ully passed, it uses the segment selector rom the callgate to locate the segment descriptor or the destinationcode segment. It then combines the base address rom thecode-segment descriptor with the oset rom the call gate

    to orm the linear address o the procedure entry point inthe code segment.Figure 3-2 illustrates this process.

    Figure 3. Call-gate mechanism Source: [19]

    o execute code residing in user address space at ring 0, allthat has to be done is to add a new call gate to the GD.Te address and size o the GD can be obtained withthe SGD instruction. Te GD is located at the system

    address space, so either physical memory device or ntdll!ZwSystemDebugControl technique can be used towrite the new call-gate descriptor to the GD. Te Off-seteld o the new call-gate descriptor will point to thepayload code. Te Segment Selector eld shouldbe set to a code segment that executes at ring 0. Te nalthing to remember is to grant access to the call gate romuser mode by setting the DPL eld to value 0x3.

    Call gates are not a common technique used by todaysmalware. Te author has only encountered one casewhere a malware used this technique to access ring 0. Tismalware is detected as Email-Worm.Win32.Gurong.a4[10][6]. Gurong.a installed a call gate through the physical4. Also detected as W32.Mydoom!gen (Symantec) and W32/My-Also detected as W32.Mydoom!gen (Symantec) and W32/My-Also detected as W32.Mydoom!gen (Symantec) and W32/My-tob.genMM (McAee).

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    8/15AVAR 2006 - AucklAnd

    memory device. Te ring 0 code was used to hide its pro-cess, le, and launch point rom the registry. It achievedthis by hooking unctions romnt!KiServiceTableand by removing its process object rom internal kernellists.

    usig kereMoe Spport Roties

    o ulll the requirements or ull-kernel malware themalware has to execute its entire payload in ring 0. Tediculty level o implementing such malware can varyrom hard to impossible depending on the set o eaturesit has to support. In case o a basic downloader, it prob-ably needs to perorm ollowing operations:

    It allocates memory or storing temporary data

    It accesses internet to download the new payload

    It stores the le on the le system

    It modies the registry to make sure the new pay-load will be executed

    Te Windows kernel provides a set o documented sup- port routines that can be used by kernel-mode driversto perorm various tasks. Tese are documented in the Windows Driver Kit (WDK) [22], which was previ-ously known as the Windows DDK. In addition WDKcontains many source code examples how dierent tasks

    can be perormed. From the above list all tasks except ac-cessing internet are very simple to implement rom kernelmode. Following unctions would do the job:

    ExAllocatePoolWithag / ExFreePoolWithag

    ZwCreateFile / ZwWriteFile / ZwClose

    ZwCreateKey / ZwSetValueKey / ZwClose

    I the reader is amiliar with Native API, then Zw* unc-tions should look amiliar. An excellent reerence withunction prototypes is the Native API Reerence book byNebbett [19]. Te kernel exports only a subset o the unc-tions that are exported by Ntdll.dll. On WindowsXP SP2 this subset consists o approximately 130 unc-tions out o 280. In case o unexported unctions there areways to nd the correct address to call. Te best o them,and oen used by malware, is to get this inormation romNtdll.dll [27]. Every Zw* unction in Ntdll.dllis implemented in similar way. Below is the disassem-

    bled version ontdll!ZwWriteVirtualMemory:0x7C90EA32: B815010000 MOV EAX,0x115

    0x7C90EA37: BA0003FE7F MOV EDX,0x7FFE0300

    0x7C90EA3C: FF12 CALL DWORDPTR[EDX]

    0x7C90EA3E: C21400 RET 0x14

    Te rst instruction, MOV EAX, 0x115, tells the Sys-tem Service Dispatcher (SSD) that it should call unctionpointer rom nt!KiServiceTable located at index0x115. Tis unction pointer is the address o the realservice unction that will perorm the requested task. Inthis case it would be nt!NtWriteVirtualMemory.

    Te basic idea is to load Ntdll.dll image rom diskinto memory and then to nd the entry point o the re-quired unction rom the PE headers export table. Fol-lowing simple piece o code etches the index which canthen be used to get the correct unction pointer rom theservice table.

    ulSSN = *(PULONG)((PUCHAR)pbNativeAPIFunction + 1);

    Tis allows kernel-mode code to have the ull Native APIin its arsenal. However, there are still limitations what canbe done and when. Tis is mostly caused by the act thatkernel-mode code can execute in one o three contexts user thread, system thread or random. I the code executesin user thread context and the threads PreviousModeeld equals UserMode, then extra argument validationis done or the passed parameters. Tis means that anypassed pointers must reside in user address space or oth-erwise the operation will ail. Te easiest way to solve thisis to make sure the routines are always called rom system

    thread context.

    One topic that has not yet been discussed is how internetcan be accesses rom ring 0. Tis is an important eatureor the simple downloader since otherwise it will not beable to etch the new payload. Tis is currently the hottopic in the eld o kernel malware. It is worrying to seehow the number o working solutions with ull sourcecode is published by various authors [28][29][30][15]15]]that will eventually make it easier or more malware to

    enter the kernel. Tis topic is worth another research pa-per and will not be discussed any urther.

    Exetig coe i Rig 3

    In an ideal world kernel malware should do all its tasksrom ring 0. However, this is not always easible since itwould require too much eort to implement some librar-ies that are only available rom user mode. In addition,there are situations where it is benecial or the malware

    to execute at high enough level. A good example o suchmalware is a trojan that steal users banking credentials.Normally, communication between the client and serveris encrypted and encryption is done at user mode. I themalware intercepted the data rom kernel mode, it would

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    9/15AVAR 2006 - AucklAnd

    already be in encrypted ormat. In this case a better ap-proach would be to execute parts o the code in ring 3 inthe context o the process where the credentials are storedbeore encryption.

    Malware that initially executes at ring 0 but later executes parts o its payload in ring 3 has been very rare to theauthors knowledge. Virus.Win32.Chatter, which was al-ready mentioned, is one o them. Also, both sample casesthat will be investigated in more detail in the case studiesuse this approach.

    Tere exist two methods that have been used by malwareto accomplish this. First one involves allocating memoryrom the target process, writing the payload into the allo-cated buer, and nally making sure that the process willexecute the payload either by hooking some unction orby modiying the context o one o its threads. Te second

    one uses Asynchronous Procedure Call (APC) mecha-nism provided by the OS. Te benet o the second tech-nique rom the malware point o view is that APC is anormal operation and it would be very hard to identiymalicious APC operations amongst legitimate operationsperormed by the OS itsel.

    Solomon and Russinovich [34] dene APC as a unctionthat provides a way or ring 3 and ring 0 applications toexecute code in the context o a chosen user thread andhence a process address space. Windows OS supportsboth user- and kernel-mode APCs. User-mode APC canbe used to execute code in ring 3.

    Te idea o using user-mode APC to execute code romkernel mode in ring 3 is not new. Anatoly Vorobey alreadybrought out this idea in year 1997 [25]. However, his ap-proach did not take into account the need to allocate andmap the ring 3 payload code into the address space o thetarget process. A complete solution with ull source code was published in rootkit.com by Valerino in February

    2005 [31]. Below is a skeleton code to execute code romkernel mode in ring 3.

    pMdl = IoAllocateMdl(pPayloadBuf,dwBufSize, FALSE,FALSE,NULL);

    // Lock the pages in memory_ _ try{

    MmProbeAndLockPages(pMdl, KernelMode,IoWriteAccess);}

    _ _ except (EXCEPTION _ EXECUTE _ HANDLER){}

    // Map the pages into the specifed process

    KeStackAttachProcess(pTargetProcess,&ApcState);

    MappedAddress = MmMapLockedPagesSpecifyCa

    che(pMdl, UserMode, MmCached, NULL, FALSE,NormalPagePriority);KeUnstackDetachProcess(&ApcState);

    // Initialize APCKeInitializeEvent(pEvent, NotifcationEvent,

    FALSE);KeInitializeApc(pApc, pTargetThread, Origi-nalApcEnvironment, &MyKernelRoutine, NULL,

    MappedAddress, UserMode, (PVOID)NULL);

    // Schedule APCKeInsertQueueApc(pApc,pEvent,NULL,0)

    One important thing with user-mode APC is that the tar-get thread has to be in alertable state beore it will call theAPC unction [37].

    So ar the author has seen Valerinos technique, which isthe most advanced one, to be used by only one malware

    amily, named Spamool.Win32.Mailbot5. In many waysthis malware amily is special and applies lots o ideaspresented by various rootkit researchers into real-lie mal- ware. Mailbot will be discussed in more detail in CaseStudy 2, later in this paper.

    Ce Sudy 1 Hxd

    Haxdoor [7][8] is a powerul backdoor with rootkit andspying capabilities. It has been around or a long time butespecially during year 2006 it has received lots o attentionbecause o its involvement in various high-prole phish-ing, pharming and identity the attacks [13][14][1].Haxdoor is a good example o todays malware that uti-lizes kernel-mode code to make its detection and removalmore dicult and to circumvent personal rewalls.

    First Haxdoor, named Backdoor.Win32.Haxdoor.a6, wasound in August 2003. It had three components, a PE exe-cutable, a DLL and a kernel-mode driver. Te executables

    main purpose was to install and launch the other compo-nents. Te DLL was the main part implementing back-door and inormation stealing unctionality. It utilizedthe driver when it had to do operations that cannot bedone rom user mode on Windows N based platorms.Te services include low-level I/O operations, dumpingo SAM database to a le and hooking o nt!NtQuerySystemInormation rom nt!KiServiceTable to hidehaxdoors process rom other applications.

    From those times Haxdoors driver has evolved but inter-estingly many o the old eatures are still present, includ-

    5. Also known as Backdoor.Rustock.A (Symantec) and Spam-Mail-Also known as Backdoor.Rustock.A (Symantec) and Spam-Mail-Also known as Backdoor.Rustock.A (Symantec) and Spam-Mail-bot trojan (McAee).6. Also detected as Backdoor.rojan (Symantec) and BackDoor-Also detected as Backdoor.rojan (Symantec) and BackDoor-Also detected as Backdoor.rojan (Symantec) and BackDoor-BAC rojan (McAee).

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    10/15AVAR 2006 - AucklAnd

    ing I/O operations to enable/disable the keyboard, play-ing such tricks as opening and closing the CD-ROM trayor in the worst case resetting the CMOS.

    During the last year, Haxdoor driver has changed verylittle. Te driver is actually very simple but still does someextremely powerul tricks to make detection and removalo it hard unless its inner workings are well known. Belowis the list o most important eatures it implements:

    process and le hiding

    protection o its own threads and processes againsttermination

    protection o its own les against any access

    payload injection into created processes

    Surprisingly it still misses some important eatures such ashiding o its launch points rom the registry. oday, basiceature set o a rootkit-enabled malware includes at leasthiding o its les, registry keys/values and processes.

    Process and le hiding are implemented by replacingunction pointers or nt!NtQuerySystemInformation and nt!NtQueryFileInformation innt!KiServiceTable with special hook unctionsimplemented by the driver. Tese hook unctions rst

    call the original service unction that etches the corre-sponding inormation rom the system beneath and thenremove any entries rom the collected data that the mal-ware wants to hide rom other applications.

    Haxdoor protects its own threads and processes in a simi-lar way. Instead it now hooks nt!NtOpenThread andnt!NtOpenProcess. I the hook unction noticesthat another process tries to open a handle to the malwareprocess or any o its threads with PROCESS _ TERMI-NATE or THREAD _ TERMINATE access rights, it

    replaces the target id with the one o the calling thread orprocess respectively. Tis results that the thread or processtrying to terminate the malware gets terminated instead.

    Figure 4. Haxdoor protects its own process against termi-nation.

    Haxdoors le protection scheme is very simple but ex-tremely powerul. Any user-mode code has a hard timetrying to get access to any le under protection by themalware driver. When the driver starts, it rst opens ahandle to the protected les with no share access whichgives it exclusive access to them. Just as a precaution it alsotakes an exclusive lock over the whole le content by using

    nt!NtLockFile. Since this is done rom the kernel inthe system thread context, the created handle is not acces-sible rom user mode. Only way to bypass the le lockingis to do it rom kernel.

    Probably the most interesting and unique eature o thedriver is its payload injection into newly created process-es. Tis is done by hookingnt!NtCreateProcessand nt!NtCreateProcessEx unctions romnt!KiServiceTable. Te ormer is used on Win-dows 2000 whereas the latter is used on Windows XPand Windows Server 2003. Te consequence is thatwhen a new process is created the hook will be executed.First, the hook calls the original unction so that the newprocess is actually created. Ten, beore returning controlto the creator it executes its additional payload, which isillustrated in the ollowing gure.

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    11/15AVAR 2006 - AucklAnd

    Figure 5. Haxdoor injects its payload into newly createdprocesses beore they start to execute.

    Te payload, detour _ NtCreateProcessEx,rst checks i the calling process belongs to the back-door or i it is an important system process that shouldnot be tampered with. In case o a normal process itexecutes the code that will do the actual injection. Tepurpose o the injection is to copy the position indepen-

    dent code rom the drivers data section into the new pro-cess address space and to insert an additional hook intontdll!LdrLoadDll, which will trigger the injectedpayload when the process starts to execute. First, the driv-er calls nt!NtProtectVirtualMemory to changeprotection to allow writing to those virtual memory pag-es that will be overwritten by the hook. Ten, it allocatesmemory rom the process address space and writes theinjected payload into it. Finally, it overwrites the begin-ning ontdll!LdrLoadDll with a relative JMP in-

    struction pointing to the new payload.Te outcome is that whenever the process starts to load aDLL the injected code will be executed. What this codeactually does is out o the scope o this paper. Briefy, it willprevent various security product related processes romstarting, it will load and execute the backdoor DLL andit will install additional hooks into numerous networkrelated unctions that will allow it to conduct phishing,pharming and stealing o user credentials.

    Haxdoor is special in many ways. Its early deploymento kernel-mode code and rootkit techniques has made itto stand out rom the rest. Its usage o kernel-mode hid-ing, sel-protection and remote injection techniques hasmade it challenging or security products to deal with.

    In todays standards its rootkit techniques are nothingspectacular and properly designed kernel-mode real-timeantivirus scanners can easily detect and disable its les.However, Haxdoors code injection technique can still beconsidered extremely powerul and is still able to bypassseveral rewalls even though protection against remotecode injection is considered to be a basic requirement or

    a modern rewall.

    Ce Sudy 2 l C

    Mailbot [9] is the most powerul and stealthiest rootkitseen so ar. In many ways it puts into practice the ideaso Stealth by Design malware introduced by JoannaRutkowska in January 2006 [33]. Latest Mailbot vari-ants have only a single kernel-mode driver. However, theyare not ull-kernel malware since they carry an encrypted

    DLL that will be executed in ring 3. Te DLL is a highlysophisticated spambot with backdoor capabilities. oday,Mailbots detection and removal is still a challenge tomost rootkit detectors and antivirus solutions.

    First Mailbot, named Spamool.Win32.Mailbot.a7, wasound in December 2005. It had three components, aPE executable, a DLL and a kernel-mode driver. TePE executable was a dropper, which installed the othercomponents. Te DLL was the main component and itwas loaded into Winlogon.exe process when the systemstarted. Te kernel-mode driver hooked three unctionsrom nt!KiServiceTable, namelynt!NtEnumerateKey,nt!NtEnumerateValueKey and nt!NtQueryDirectoryFile. Teir purpose was to hide all lesand launch points created by the malware. In addition, ithooked IRP _ MJ _ CREATE, IRP _ MJ _ CLOSEand IRP _ MJ _ DEVICE _ CONTROL handler unc-tions rom cpip driver object to hide all CP and UDPconnections the DLL had established.

    Te author analyzed his rst Mailbot variant, Spam-ool.Win32.Mailbot.az8 [25], in 27th o May 2006 a-ter it was submitted by a malware collector who hadnoticed that every rootkit detection tool he was using,including F-Secure BlackLight, was not able to ndthe rootkit. It consisted only o a single kernel-modedriver that was stored as hidden data stream attachedto the system32 older. In three weeks a new and im-proved version o BlackLight was released that was again

    able to nd the hidden driver rom the system [12].

    7. Detected also as Hacktool.Spammer (Symantec).Detected also as Hacktool.Spammer (Symantec).Detected also as Hacktool.Spammer (Symantec).8. Detected also as Backdoor.Rustock.A (Symantec) and Spam-Detected also as Backdoor.Rustock.A (Symantec) and Spam-Detected also as Backdoor.Rustock.A (Symantec) and Spam-Mailbot trojan (McAee).

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    12/15AVAR 2006 - AucklAnd

    It was evident that this malware was something special.Since then the author has been closely ollowing its evo-lution and analyzing its inner workings. Tis malwareapplies into real-lie many ideas that have been discussedin various rootkit-related sites and security conerences.From the disassembled code it becomes quite evident thatthe malware author has beneted rom source code pub-

    lished in rootkit.com and the book about rootkits [15]. Adetailed analysis o the Mailbot was recently published inVB Magazine September issue [5].

    A new variant o Mailbot appeared in 3rd o July and it went a step urther in its stealth capabilities. Interest-ingly it was named as rojan-Clicker.Win32.Costrat.a9.Since detailed inormation is available o the old variants[9][5], the rest o this chapter will talk about some o thenew eatures . Figure 6shows the new main routine o arecent Costrat variant.

    Figure 6. Main routine o rojan-Clicker.Win32.Costrat.

    Spamool.Win32.Mailbot.az took control o the SystemService Dispatcher (SSD) by hookingINT 0x2E andIA32 _ SYSENTER _ EIP MSR handler unction. Athread trying to execute any o the ollowing service unc-tions was redirected to a modied version by setting thethreads KTHREAD->ServiceTable eld to point toanother table created by the malware.

    NtCreateKey

    NtDeviceIoControlFile

    NtEnumerateKey

    9. Detected also as Backdoor.Rustock.B (Symantec) and Spam-Detected also as Backdoor.Rustock.B (Symantec) and Spam-Detected also as Backdoor.Rustock.B (Symantec) and Spam-Mailbot.c trojan (McAee).

    NtOpenKey

    NtQueryKey

    NtQuerySystemInformation

    NtSaveKey

    Mailbots approach to hook service unctions on a thread-level basis was unique and the stealthiest seen so ar. Fo-rensic tools have mainly been looking or hooks romnt!KiServiceable and rom inside system service unc-tion. Tus they were not successul in nding mailbotshooks. Te problem was still that some more advancedtools checked the address oINT 0x2E and IA32 _SYSENTER _ EIP MSR handler unctions. I the ad-dress was outside the kernel module, it was a clear indica-tion that something suspicious was going on.

    Costrat solved this problem by searching or unusedmemory inside the kernel module and then redirectingthe hook through this address. Tis is clearly illustratedby the ollowing kernel debugger dumps:

    kd> rdmsr 176

    msr[176] = 00000000`806c15bd

    kd> lm a 806c15bd

    start end module name

    804d7000 806e2000 nt

    kd> u 806c15bd

    nt! _ NULL _ IMPORT _ DESCRIPTOR

    (nt+0x1ea5bd):

    806c15bd e9a249bd77 jmp

    lzx32!SysCallHookGen (f8295f64)

    Te debugger output shows that the handler unction isin address0x806c15bd which is inside the kernel mod-

    ule. Te disassembly o the handler unction shows howCostrat redirects the execution through this address tothe real hook unction.

    Latest Costrat variants have introduced a new eature thathas not previously been available. Tey hook a new sys-tem service unction named NtTerminateProcess.Te actual hooking is implemented in identical way butthe hook itsel is special. Te purpose o the hook is to al-low or the injected DLL to communicate with the driver without leaving any extra traces to the system. Figure 7Figure 77

    shows the disassembly o the kernel-mode hook unctionand the relevant code rom the DLL where the covertchannel is used.

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    13/15AVAR 2006 - AucklAnd

    Figure 7. User-mode DLL uses the priate communicationchannel and instructs the drier to update itsel.

    Latest Costrat variants are able to update themselves on-the-fy rom the control servers. Te DLL uses its privatecommunication channel to instruct the driver to replaceits le on the disk with the new version. Ten it com-mands the driver to inject and execute the new DLL intoservices.exe. Finally the old DLL releases its resources andterminates. From this point onwards the new DLL is ac-tive and interoperates with the old driver. Te new kernel-mode code is taken into use only aer reboot. Lately thiseature has been used quite oen to update the list o IPaddresses and DNS names it uses when it needs to con-nect to its control server. Tis makes it extremely hard todisable the bot network by trying to shutdown its controlservers.

    Mailbot aka Costrat is powerul. It has eatures that shouldnot go public. One example is its ability to ully bypasslter drivers. Real-time antivirus scanners and some re-

    walls are oen implemented as lter drivers. Tey cant doanything i the malicious data never goes through them.

    Cnlun

    Current security solutions, including antivirus scannersand rewalls, have not been designed to protect the end-user against malicious soware that operates in ring 0.Tere are good reasons or this. One reason is that oncethe malware executes its code with same privileges as the

    OS itsel, it will become an arms race between the goodand bad. Tis has already been seen with rootkits and theiranti-detection engines. Aer the rootkit notices that it isno longer able to hide rom the rootkit detector and isgoing to loose the game, it changes tactics and starts tomake a direct attacks against the detector. It might take amore aggressive approach and prevents the rootkit detec-tor rom starting. Or it could directly patch the rootkitdetectors code to change its inner logic.

    Te statistical analysis that was perormed, and discussedin the earlier section on History and rends, showedthat there has been a visible rise in the number o mal-ware employing kernel-mode modules as part o theirpayload. Majority o the modules have been kernel-mode

    rootkits that the malware uses to hide its main compo-nent and thus make its detection and removal as dicultas possible.

    Tis paper has shown the basic techniques that kernelmalware is using to do their job. Teir main role has beento perorm some specic tasks or the main user-mode

    component. However, the scene is changing. Tere hasbeen lots o interest in various research groups to inves-tigate or the possibilities to do more complex tasks di-rectly rom kernel. Te next big thing is going to be thenetwork side. Tis year we have already seen presenta-tions talking about how backdoors can be implementeddirectly rom kernel mode using only the NDIS layer andcustom CP/IP stack. We have also seen a presentationabout bypassing personal rewalls rom kernel-mode.

    Finally, the antivirus industry has seen rojan-Clicker.

    Win32.Costrat aka Backdoor.Rustock.B. For any mal-ware researcher who has been analyzing kernel malwarethis case should have been an eye-opener. It has shownthat complex tasks can be done rom kernel mode with-out aecting the overall system stability. Now, it is time tostart thinking how this threat can be countered.

    Reeene

    AusCER - Media Release - Response to recentmedia coverage o the A-311 Death (aka: Haxdoor)trojan. Available rom:

    Chiriac, Mihai. (2003). Virus Analysis 2: XP, ANew Virus Playground. Virus Bulletin MagazineJune 2003. ISSN 0956-9979. pp. 7-8.

    Crazylord. (2002). Playing with Windows /de/(k)mem. Phrack Magazine, Issue 59. Available

    rom:

    Florio, Elia. (2005). Feature 2: When Malware Meets Rootkits. Virus Bulletin Magazine Decem-ber 2005. ISSN 0956-9979. pp. 7-10.

    Florio, Elia; Pathak, Prashant. (2006). RootkitAnalysis: Raising the Bar, Rustock and Advancesin Rootkits. Virus Bulletin Magazine September2006. ISSN 1749-7027. pp. 6-9.

    F-Secure Virus Inormation Pages : Gurong.A.Available rom:

    1.

    2.

    3.

    4.

    5.

    6.

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    14/15AVAR 2006 - AucklAnd

    F-Secure Computer Virus Inormation Pages:Haxdoor. Available rom:

    F-Secure Computer Virus Inormation Pages:Haxdoor.ki. Available rom:

    F-Secure Rootkit Inormation Pages: Mailbot.AZ. Available rom:

    F-Secure: News fom the Lab - March o 2006 -How Would You Like Your Bagle Done, with Root- kits on the Side?Available rom:

    F-Secure: News fom the Lab March o 2006 From Russia with Rootkit. Available rom:

    F-Secure:News fom the Lab June 2006 Hid-ing the Unseen. Available rom:

    F-Secure: News fom the Lab - August o 2006

    - Haxdoor.KI Being Spammed. Available rom:

    F-Secure: News fom the Lab - October o 2006 -Denmark targeted. Available rom:

    Hoglund, Greg; Butler, James. (2005). Rootkits:Suberting the Windows Kernel. Upper Saddle

    River, NJ. Addison-Wesley Proessional. 324 pag-es. ISBN 0-321-29431-9.

    Intel. (2006). Intel 64 and IA-32 ArchitecturesSoware Deelopers Manual. Volume 1: Basic Ar-chitecture. Mt. Prospect, IL, Intel Corporation.Available rom: < p://download.intel.com/de-sign/Pentium4/manuals/25366521.pd>

    Intel. (2006).Intel 64 and IA-32 Architectures So-

    ware Deelopers Manual. Volume 2A: InstructionSet Reerence, A-M. Mt. Prospect, IL, Intel Cor-poration. Available rom:

    7.

    8.

    9.

    10.

    11.

    12.

    13.

    14.

    15.

    16.

    17.

    Intel. (2006).Intel 64 and IA-32 Architectures So-ware Deelopers Manual. Volume 2B: InstructionSet Reerence, N-Z. Mt. Prospect, IL, Intel Cor-poration. Available rom:

    Intel. (2006). Intel 64 and IA-32 ArchitecturesSoware Deelopers Manual. Volume 3: SystemProgramming Guide. Mt. Prospect, IL, Intel Cor-poration. Available rom:

    Ionescu, Alex. (2006). Suberting Windows 2003SP1 Kernel Integrity Protection Available rom:

    Kasslin, Kimmo; Stahlberg, Mika; Larvala, Sam-

    uli; ikkanen, Antti. (2005).Hide n seek reisited ull stealth is back. IN: Proceedings o the 15thVirus Bulletin International Conerence, 5-7 Oc-tober 2005, Dublin, Ireland. Abingdon, England,Te Pentagon. pp. 147-154.

    Microso: Windows Driver Kit (WDK) Over- view. Available rom:

    Nebbett, Gary. (2000). Windows N/2000 Na-

    tie API Reerence. Indianapolis, Indiana, SamsPublishing. 528 pages. ISBN 1-5787-0199-6.

    Nikishin, Andy. (1999). Virus Analysis 2, InsideIns. Virus Bulletin Magazine November 1999.ISSN 0956-9979. p. 8.

    N Drivers: Usenet Archives - Forum: comp.os.ms-windows.programmer.nt.kernel-mode User mode APCs. Available rom:

    Randnut. (2004). Multiple WinXP kernel ulnscan gie user mode programs kernel mode priileg-es. Bugraq February 18. Available rom:

    Rootkit.com: Simple Hooking o Functions not Ex-ported by Ntoskrnl.exe. Available rom:

    Rootkit.com: Kernel mode sockets library or themasses Available rom:

    Rootkit.com: Kernel mode IrcbotAvailable

    18.

    19.

    20.

    21.

    22.

    23.

    24.

    25.

    26.

    27.

    28.

    29.

  • 8/14/2019 kasslin AVAR2006 KernelMalware paper

    15/15

    rom:

    Rootkit.com:some ideAs About steAlth or rootkitAvailable rom:

    Rootkit.com: Showtime : *WORKING* Cre-

    ateProcess in KernelMode!Available rom:< h t t p s : / / w w w . r o o t k i t . c o m / n e w s r e a d .php?newsid=259>

    Russinovich, Mark. (1998). Ns \de\kmem.Available rom:

    Rutkowska, Joanna. (2006). Rootkit Hunting s.Compromise Detection. IN: Proceedings o the

    2006 Black Hat Federal, 25-26 January, Washing-ton DC. Seattle, WA, Black Hat, Inc.

    Solomon, David; Russinovich, Mark. (2005).Microso Windows Internals: Microso WindowsSerer 2003, Windows XP, and Windows 2000.4th edition. Redmond, Washington. MicrosoPress. 935 pages. ISBN 0-7356-1917-4.

    Szor, Peter. (2000). Virus Analyses: Poetry In Mo-tion. Virus Bulletin Magazine April 2000. ISSN

    0956-9979. pp. 6-8.

    Szor, Peter. (2005). Te Art o Computer Virus Research and Deense. Upper Saddle River, NJ.Addison-Wesley Proessional. 744 pages. ISBN0-321-30454-3.

    Microso Platorm SDK Documentation Avail-able rom:

    Hoglund, Greg. (2000). Loading Rootkit Us-ing SystemLoadAndCallImage. Bugraq August29. Available rom:

    30.

    31.

    32.

    33.

    34.

    35.

    36.

    37.

    38.