Vbootkit 2.0 has now been made open-source under GPL license.

Vbootkit 2.0 currently only works on Windows 7 ( x64 edition ).

SHA1SUM: 1ddc2bc03e47b0251f5f65cb6dce31fb5aa2c86b vbootkit2.zip

Download Vbootkit 2.0 source code

Vbootkit 2.0 Attacking Windows 7 (x64) via Boot Sectors presentation

Vbootkit 2.0: Attacking Windows 7 via Boot Sectors

This talk will introduce a new tool which allows attacks against Windows 7 via boot sectors. In this talk we will demo Vbootkit 2.0 in action and show how to bypass and circumvent security policies / architecture using customized boot sectors for Windows 7 (x64). The talk will cover:

() Windows 7 Boot architecture
() Vbootkit 2.0 architecture and inner workings
() insight into the Windows 7 minkernel

We will also demonstrate:

() The use of Vbootkit in gaining access to a system without leaving traces
() Leveraging normal programs to escalate system privileges
() Running unsigned code in kernel
() Remote command & Control

All this is done, without having any footprint on the HDD (everything is in memory). It also remains invisible to all existing anti-virus solutions.

Vbootkit 2.0 Attacking Windows 7 (x64) via Boot Sectors

This projects details the Internals/Implementaion of BitLocker Encryption system for Vista.

NVbit is a linux fuse driver to access Windows Vista's Bitlocker Volumes from linux, provided you have the right keys.A white-paper and supporting presentation is also available.The research was done around an year ago.Work was stopped prematurely,Don't expect things in clean/finished shape.The code is in alpha state.
Both the paper and presentation are incomplete draft versions. However, missing things can be referred from nvbit source code.NVbit allows read-only access.(Though writing can be done just in reverse order but still it doesn't exist for now).

NVbit source sode
NVbit Bitlocker presentation
NVbit Bitlocker white_paper

What is Vbootkit?

Nitin & Vipin: Vbootkit is much like a door or a shortcut to access vista's kernel.

A bootkit is a rootkit that is able to load from a boot-sectors (master
boot record, CD , PXE , floppies etc) and persist in memory all the way
through the transition to protected mode and the startup of the OS.

http://www.securityfocus.com/columnists/442

Vbootkit White-paper and presentation materials

The vbootkit white-paper and presentation slides are now online and can be downloaded below.

Vbootkit Presentation
Vbootkit White Paper

nitin_vipin_vista_vbootkit_poc_RC1_edited_video.avi
nitin_vipin_vista_vbootkit_poc_RC2_video.avi

BOOT KIT is a project related to custom boot sector code subverting
Windows NT Security Model.The sample presented currently keeps on
escalating cmd.exe to system privileges every 30 secs.

It has several features

1. It's very small.The basic framework is just about 100 lines of assembly code.It supports 2000,XP,2003
2. It patches the kernel at runtime(no files are patched on disk).
3. BOOT KIT is PXE-compatible.
4. It can even lead to first ever PXE virus
5. It also enables you to load other root kits if you have physical
   access(Normally root kits can only be loaded by the administrator

The bootkit has been tested with a number of kernel mode shell codes such as Loading Native Applications and drivers from the shell code

another shellcode ,which periodically raises every CMD.EXE to system privileges.

The Source code will contain 4 levels of BOOT KITs(showcasing different payloads)

1. Basic framework ( Kernel patching has to be done later on) ( available for download )
2. Privilege escalation framework(demonstrates creating new system
   threads and how to escalate privileges easily) (available for download)
3. Loading drivers and native applications from kernel mode without touching registry
4. PXE compatible code(Basic framework).

Bootkit Basic framework Source Code
Boot Kit Advance Version(support Privilege escalation) Source Code

"How to load driver without touching registry from kernel mode", this is asked almost always.Today,
I will give you an insight into how Windows loads its driver and then will document a new method to load a driver without touching registry.

This is required because even if you exploit kernel vulnerabilities, you still cannot load any driver because almost all existing Antivirus solutions hijack the NTOSkrnl API's ( which let you write to specific registry locations, load drivers etc).

Continue reading "Loading drivers and Native applications from kernel mode, without touching registry"