Jump to content
Tuts 4 You

Advanced Windows Hooking Techniques (STEALTHY INSTRUMENTATION TECHNIQUES)


Techlord

Recommended Posts

Hooking Nirvana - STEALTHY INSTRUMENTATION TECHNIQUES : (Old but an excellent refresher. Bonus is that techniques work on Windows 10)

Full VIDEO of the talk available here (56 Mins) - from Recon 2015.

 

WHAT THIS TALK IS ABOUT :
 

Quote

 

Five different technologies in Windows:
          ◦Time Travel Debugging / iDNA(Nirvana)
          ◦Application Verifier (AVRF)
          ◦Minimalized Windows (MinWin)
          ◦Application Compatibility Engine (ShimEng)
          ◦Control Flow Guard (CFG)


Their intended use in the system and

How their use can be misappropriated or leveraged for instrumenting binaries and hooking them early (or late).

 

 

All this is looked at from the perspective of Windows 10 and the changes in Windows 10 :
 

Quote

 

WINDOWS 10 CHANGES

So we’ll specifically take a look at new changes in Windows 10

◦New data structures and types
◦New version numbers
◦New API parameters/exports/techniques
◦Semantic/functional changes

 

 

OUTLINE :

Quote

MinWinHooks
Nirvana Hooks
CFG Hooks
AVRF Hooks
Shim Hooks

 

 

Quote

 

What is MinWin?

MinWinis an internal Microsoft project to re-architect the many layers of the Windows Operating System

  • Goal is to return to the original layering interface that Dave Cutler wanted –a low-level microkernel, a set of base services, and a subsystem of additional functionality
  • First “shipped” in Windows 7
  • People started noticing strange new DLLnames as well as import tables
  • Came in as an “API Contract” mechanismused by user-mode applications
  • Enhanced in Windows 8
  • Supported by the kernel and even bootloader

Made “One Core” possible in Windows 10

 

 

 

Quote

 

Nirvana and iDNA/TTT

Using Nirvana, Microsoft has an internal tool called iDNA, which is also used for Time Travel Tracing (TTT) and TruScan

·          We keep hearing about these amazing, incredible, Microsoft internal tools in MSR Papers and other conferences

·          We will never get to use them

·         How can Nirvana do its job without angering PatchGuard?

·         In the Windows 7 SDK, Microsoft (accidentally?) leaked out a key definition that showed what the magic behind Nirvana: a dynamic instrumentation callback

·          Accessible through NtSetInformationProcesswith the ProcessInstrumentationCallbackclass

·          Takes a pointer to a function

 

Instrumentation Callback (Win 7) :

 

In Windows 7, the instrumentation callback is set with a simple line:

NtSetInformationProcess(NtCurrentProcess(), ProcessInstrumentationCallback, &callback,sizeof(callback));

·         It only works on x64 Windows

·         It doesn’t support WoW64 applications

·         It requires DR7 to be set for most cases (i.e.: an attached debugger)

·         It doesn’t catch NtContinueand NtRaiseException

·         Requires TCB privilege, even if setting on self!

 

 

Instrumentation Callback (Win 10)

In Windows 10, the instrumentation callback is registered with a structure:

typedefstruct_PROCESS_INSTRUMENTATION_CALLBACK_INFORMATION{ULONG Version;ULONG Reserved;PVOID Callback;} PROCESS_INSTRUMENTATION_CALLBACK_INFORMATION;

·         Version must be 0 on x64 Windows and 1 on x86 Windows

·         Reserved must be 0

·         Yep, it now works on x86 Windows

·         It also supports WoW64 applications

·         No longer requires DR7 to be set

Now catches NtContinue, but on x86 only

 

 

 

Quote

 

CFG Bonus

CFG in Windows 10 covers a lot more that no one has yet talked about

Nirvana Hooks are protected by CFG to avoid using them as a bypass 

MmCheckForSafeExecutionprotects the ATL Thunkemulation to avoid using it as a CFG bypass J

RtlGuardIsValidStackPointeris used with “Check Stack Extents” mode

·         For example, when using NtContinueor SetThreadContext, stack addresses are validated

·         (Rtl)SetProtectedPolicy/(Rtl)QueryProtectedPolicyare new user-mode APIs to associated protected data with GUIDs

·         Data is stored in a protected “Mrdata” heap

·         Only active if CFG is enforced

·         .mrdatasection contains key CFG variables and function pointers

 

 

 

Quote

 

Conclusion :
Windows has a variety of DLL hijacking/loading functionality built-in
Most of it is accessible through various undocumented flags, structures and mechanisms
It is slowly being secured, in some cases, but other mechanisms are still wide open for attack
These mechanisms not only allow for hijacking, but also persistence, and in some cases emulation defeats (such as the instrumentation callback)
People need to take a deeper look at CFG –not everything has yet been revealed

 

 

 

 

Relevant code can be found here .

Edited by Techlord
  • Like 6
Link to comment
1 hour ago, nimaarek said:

It could be interesting...  can i have presentation slide?

The download link in the post contains the presentation PDF in it as well. Just a tiny download..

Link to comment
1 hour ago, Sound said:

useful information. Thanks for sharing!

Yes bro @Sound : This contains info on FIVE methods of SYSTEM-LEVEL hooking and that too on Windows 10 !

Added to that , most of the methods are "official" methods .. Thats what  makes it so interesting :D

Link to comment
  • 3 years later...

Alex Ionescu: "Hmmm, let's google to see what I can present at REcon 2015..."

Alex Ionescu: "Damn, I found this amazing article from 2013: https://www.codeproject.com/Articles/543542/Windows-x64-system-service-hooks-and-advanced-debu, I will use this!"

Alex Ionescu: "Presents at REcon 2015..."

Internet later: "Ohhh woooooow! NIRVANAAA GG Alex Ionesc! Would you like a new job ?!!".

 

Absolutely disgusted.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...