Subscribe to feed Latest Entries

Automated Rootkit Detection with ThreatSCOPE

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Friday, 14 March 2014
in Use Cases

This article will show how you can use the ThreatSCOPE feature of WindowsSCOPE to detect rootkits installed on a system. One of the difficulties in detecting rootkits and other advanced malware is that they’re often packed, encrypted, or injected by other means than being run from an executable file on the disk. This means they can easily slip past most common antivirus tools that only look on the disk. This is why you need an in-memory tool like WindowsSCOPE to detect these types of advanced threats. In this post we’ll show how to detect the Hacker Defender rootkit (hxdef) using the new ThreatSCOPE feature.

One of the most effective ways to detect rootkits and other malware is by comparing against a known-good system state. When a rootkit is suspected, huge amounts of time can be saved in finding malicious changes by narrowing the search to only what has changed in the system. This is the idea that ThreatSCOPE is based on, and how we quickly detected changes that were made by the hxdef rootkit. So the first thing we did before running the hxdef loader was to take a memory snapshot before introducting the rootkit. Then, after installing hxdef, we took a second memory snapshot. After importing these snapshots into WindowsSCOPE, we used ThreatSCOPE to run a code comparison on ntdll.dll. You can see the comparison results in this screenshot:

ThreatSCOPE Analysis Results

Based on the analysis results, it looked like the rootkit was injecting hooks into ntdll, as this code shouldn’t be changing after it’s loaded. To find out for sure what was actually happening here, we looked up the code at the address of one of the 4 byte code changes both before and after the change. Looking in the disassembled view, we discovered that the original code at this address:

Code Before Hook

Had been changed to:

Code After Hook

Based on this we were able to identify this change as an inline hook injected into ntdll by the hxdef rootkit. We found the same results for each of the other 4 byte code modifications – a jmp instruction that was redirecting control flow to code injected by the rootkit.

 

Looking a little bit further, we were able to identify exactly which code was being hooked. We did this by searching the address of the inline hook in the export table for ntdll:

Export Table for ntdll

We found that this particular change was hooking NtCreateFile. By looking up the rest of the changes in the export table we were able to get a full list of hooks that were created in ntdll by the rootkit: NtCreateFile, NtDeviceIoControlFile, NtEnumerateKey, NtEnumerateValueKey, NtOpenFile, NtOpenProcess, NtQueryDirectoryFile, NtQuerySystemInformation, NtQueryVolumeInformationFile, NtReadVirtualMemory, NtResumeThread, and NtVdmControl.

This is just one example of how ThreatSCOPE can be used to speed up a rootkit investigation. ThreatSCOPE can also be used to quickly identify changes in the SSDT, IDT, process list, open sockets, open files, open registry keys, and other system data structures. Once suspicious changes are found you can perform more in-depth reverse engineering as necessary.


Tags: Untagged

WindowsSCOPE Cyber Forensics Ultimate 64-Bit Now Available

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Monday, 03 December 2012
in Products

The latest addition to the WindowsSCOPE product lineup, Cyber Forensics Ultimate, is now available at the online store. This new version incorporates all the interactive features of previous versions, including system-wide disassembly and control flow graphing of both user and kernel space. The 64-bit version enables support for importing memory dumps taken from any 64-bit Windows computer to your existing WindowsSCOPE repository. Visit our online store now to get WindowsSCOPE Cyber Forensics Ultimate and start analyzing your 64-bit memory dumps.

Tags: Untagged

Bypassing Windows Login Passwords with CaptureGUARD Gateway for Forensic Acquisition

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Wednesday, 29 August 2012
in Products

Live memory acquisition is becoming increasingly important for digital investigations. One of the biggest obstacles with memory acquisition, however, is that in many cases a computer under investigation is locked, requiring a password that is not available.

CaptureGUARD Gateway enables investigators to overcome this challenge by allowing them to log into a computer without knowing the password. Watch this video demonstration of CaptureGUARD Gateway unlocking XP, Vista, and Windows 7 computers.

To get a memory dump from a locked computer, an investigator could  then simply run any memory acquisition software.

Tags: Untagged

New WindowsSCOPE Product - CaptureGUARD Gateway

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Friday, 13 July 2012
in Products

WindowsSCOPE now offers PCI Express and ExpressCard platforms capable of imaging physical memory and providing other cyber security related capabilities even in locked computers.  CaptureGUARD Gateway can be customized for various advanced cyber security and forensics use-cases not possible with other solutions on the market.

Please contact us at This e-mail address is being protected from spambots. You need JavaScript enabled to view it to explore how these capabilities can be tailored to meet your needs.

CaptureGUARD Gateway

Tags: Untagged

Reverse Engineering the Vanquish Rootkit - Part 2

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Friday, 25 May 2012
in Use Cases

If you followed our prior post on the Vanquish rootkit, you might remember how we identified anomalies in a system that led us to finding a Vanquish rootkit infection. You can go back to Part 1 and review it on your own, but here is a quick summary of how we discovered the rootkit:

 

  1. Found a hidden module listed in WindowsSCOPE. We noted several strings in this module that made references to Vanquish, code injection, replacing APIs, etc.
  2. Found a function exported from the hidden module with “FindNexFile” in the name
  3. Knowing that “FindNextFile” is normally an export of Kernel32.dll, we chose to look at the code for this function
  4. Disassembling the “FindNextFile” function showed that the first instructions of the function had been replaced with a jump to the hidden module we found earlier

At this point we were pretty sure there was a rootkit present, so the next step was to take a look at the code FindNextFile was jumping to. The best way for us to reverse engineer the code with WindowsSCOPE was to generate a control flow graph for the rootkit module. To do this, we first switched to the disassembled view and navigated to the address FindNextFile was jumping to. Then we right clicked and did a workpad graph from this address. The control flow graph that we got is shown below:


 

We started out by looking at the code within the entry procedure, which was the destination of the jump that we saw in kernel32.dll. This procedure is the green diamond shaped node in the graph. The control flow graph for this procedure is shown below:

 

 

We found something suspicious in this control flow graph – code that was called by FindNextFileW is now calling FindNextFileW. But if you remember, when we looked at FindNextFileW we saw that it was hooked. At first this looks like a potential problem, but we took a close look at a procedure that was called just before FindNextFileW and found something interesting. Look at the instructions in the control flow graph for this procedure below:

 

 

 

Based on the Windows API functions this code is calling, it appears that this code is modifying instruction memory. It uses RtlLeaveCriticalSection for synchronization to make sure the code isn’t run by more than one thread at a time. Then it uses VirtualProtect to modify memory protections to allow the instruction memory to be modified. Then a procedure is called which rewrites the instruction memory. The last thing the function does is us VirtualProtect and RtlLeaveCriticalSection to restore the original memory protection and release the lock that prevents other threads from executing this code. Finally, FlushInstructionCache is called, which will resolve cache coherency problems that come up when modifying instruction memory. After a little bit of analysis, it appears that this function unhooks the FindNextFileW API call, which allows vanquish to use it when it needs to. We also found there was another function very similar to this one, which does the exact opposite. After the Vanquish rootkit is done with using the FindNextFileW function, it restores the hook that it placed in kernel32.dll. The end result is that when any other code on the system calls FindNextFileW, it calls the rootkit’s implementation of this code. Since Vanquish needs to use the real FindNextFileW function, it temporarily unhooks it while it uses it. Once the rootkit is done using the API, it puts the hook back in place, preventing other code on the system from using the real API function.

Now let’s look at how Vanquish uses the FindNextFile API. If you look back at the control flow graph we showed earlier (the second graph, which is the graph of this entry point into the rootkit), you can see that FindNextFile is called in a loop. At the beginning of the loop another procedure is called, and the return value of the procedure determines when to break from the loop. Below a piece of the control flow graph for this procedure:

 

 

You’ll notice the use of the “CharUpper” function here, which indicates that this function is doing some string manipulations. In particular, this function is using “CharUpper” to do a case insensitive compare. After some more analysis, we found that this function was looking for strings containing “vanquish”. So the loop that calls this function uses the real “FindNextFile” function and then uses this function to skip any result that contains the string “vanquish”.

This was just one of many hooks installed by Vanquish - there are others including directories, services, registry keys, etc. The same techniques demonstrated in this post can be applied to reverse engineer other hooks installed by Vanquish and other rootkits.

 

Tags: Untagged

New WindowsSCOPE Memory Forensics Training Videos Available

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Wednesday, 09 May 2012
in Tutorial videos

Two new tutorial videos are now publicly available on the WindowsSCOPE websiite - "Using WindowsSCOPE to Investigate 64-Bit Virtual Memory Management" and "Using WindowsSCOPE to Analyze the Shadow Walker Rootkit".

With 64-bit computers becoming increasingly common, the Introduction to 64-Bit Virtual Memory Management video will bring you up to speed on how Windows memory management has changed in 64-bit Windows and how you can use WindowsSCOPE to explore Windows memory.

The Shadow Walker Rootkit Analysis video takes you through an in-depth use case that demonstrates how to use WindowsSCOPE to investigate advanced cyber attacks.

Both of these videos are now available on the Movies/Tutorials page here.

Tags: Untagged

Reverse Engineering the Vanquish Rootkit - Part 1

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Monday, 30 January 2012
in Use Cases

In this blog entry we'll take a look at the Vanquish rootkit and show how we confirmend that a machine was infected with it. This rootkit is a malicious software capable of hiding files, registry keys, and services and making other changes to infected systems. When coupled with trojans, backdoors, or other malware it can make for an extremely dangerous combination, especially since it has the ability to hook some of the very API functions that antivirus and anti-malware programs use to detect threats. In this article we will walk through the process of using WindowsSCOPE to show that a system is infected with Vanquish, and then we will take a closer look at what the rootkit is doing and how it hooks the Windows API to hide files from users. We will be looking at the Vanquish rootkit that was captured in a WindowsSCOPE snapshot that was taken inside of a virtual machine.

Tags: Untagged

Introduction to Windows Kernel: Review IDT, SSDT and other Structures

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Friday, 04 November 2011
in Tutorial videos

This video focuses on exploring the internals of the Windows operating system including the IDT, SSDT, and DLL imports and exports. It is recommended that you familiarize yourself with the WindowsSCOPE software by reviewing the Quick Start Guide or watching the WindowsSCOPE introduction movie before viewing this movie.

Tags: DLL, video

Introduction to WindowsSCOPE Live

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Wednesday, 26 October 2011
in Products

This article will take you through the process of installing and configuring the WindowsSCOPE Live cyber-defense and memory forensics application. The WindowsSCOPE Live program consists of 2 important parts:

WindowsSCOPE Live mobile app - This is the client side of the program that will be running on your mobile device. This article will show you how to set up the Android version of the app. Clients for other types of mobile devices will be available in the future.

WindowsSCOPE Live Server - This is the server side of the program that runs on the Windows computers that you will be monitoring with WindowsSCOPE Live.

Tags: Untagged

Top Ten Reasons to Perform Live Memory Forensics Collection

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Friday, 14 October 2011
in General

1. Valuable information is volatile and can only be captured from live memory.

  • Once the system is shut down information/evidence about network connections and malicious processes in memory will likely be lost.
Tags: Untagged

Introduction to 64-Bit Virtual Memory Management Video

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Tuesday, 04 October 2011
in Tutorial videos

This instructional video picks up where the 32-Bit virtual memory management video left off by extending the principles of virtual memory management to 64-bit systems.  We recommend getting familiar with 32-bit virtual memory management before advancing to this video.

Virtual Memory and Address Translating for x64

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Friday, 30 September 2011
in Use Cases

Virtual addressing is a technique that gives processes the illusion of having sole access to physical memory. Every process in a system is given a virtual memory space. With 32-bit architecture, the virtual memory space of a process is limited to 4GB. With 64-bit architecture, each process is given 256TB of virtual memory. Virtual memory and physical memory are broken up into pages that are 4KB. Computers obviously do not have 256TB of physical memory. Virtual Addressing divides the usage of the physical memory so that several processes can run at the same time. So while processes may be using just a small portion of physical memory, they are given a large virtual memory space that is guaranteed to satisfy its memory needs.

Check Open Registry Keys in Memory

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Thursday, 15 September 2011
in Use Cases

WindowsSCOPE can be used to view all registry keys currently being used by Windows. The Windows Registry essentially is a database of configuration settings, for both Windows and applications. Some common things found in the registry are the paths for where files are saved by a program and information on a user profile for a program.

Introduction to 32-Bit Virtual Memory Management

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Thursday, 25 August 2011
in Tutorial videos

This instructional video uses WindowsSCOPE to show how virtual memory and paging works on 32-bit Windows systems.  Covered topics include page table entries, physical address extension, and the use of the no-execute bit.

Virtual Memory and Address Translating for x86 and x86 PAE

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Sunday, 21 August 2011
in Use Cases

Every process needs memory to store values and variables in order to function correctly. However, it is sometimes unnecessary for all of the memory belonging to a process to be present in physical memory (RAM). Physical memory needs to be available to all of the processes on a computer; it can’t get completely filled by one large process. Virtual memory solves this problem by utilizing space on the hard drive when there is not enough physical memory for all of the processes to occupy.

Comparing Open Network Sockets

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Monday, 15 August 2011
in Use Cases

The Compare Tool for WindowsSCOPE has a variety of uses, with an important one being able to compare open network sockets. A snapshot can be taken before a program, during, and then after the program has been run. This will allow WindowsSCOPE to show which ports the program has opened for use. To get the best results, close out of all programs except for WindowsSCOPE and the program being analyzed. This will make the list a lot easier to look through.

How to Compare Multiple Memory Snapshots

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Saturday, 30 July 2011
in Use Cases

WindowsSCOPE allows virtually anything found in a snapshot to be compared to another snapshot. This is useful for seeing how a computer changes over time. For instance, the process table can be compared to see the change in processes running at the time of each snapshot. To get a good feel for the features of the Compare Tool, an example snapshot was taken before the anti-virus software AVG was installed and then another snapshot was taken shortly after the installation finished. The AVG software was then uninstalled and another snapshot was taken to see what was left behind.

Rootkit Video Series: Understand and Detect the Shadow Walker Rootkit

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Sunday, 10 July 2011
in Tutorial videos

This video demonstrates how WindowsSCOPE can be used to reverse engineer real malware and rootkits. In this video we investigate the Shadow Walker rootkit. You will witness how WindowsSCOPE uncovers its hooks on the virtual memory system.

Review all Open Files Accessed by Processes in Memory

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Wednesday, 06 July 2011
in Use Cases

WindowsSCOPE can be used to view all files being accessed by the system at the time of a snapshot being taken. To view all files being accessed go to Memory View → Summary of System Activity → Open Files on the left panel. All files being accessed by a specific process can be viewed by going to Memory View → Processes → → Open Files. Three columns 'File Name', 'Process', and 'Access Rights' should be visible in the center panel as seen below.

How to Capture/Analyze Network Activities from Memory

Posted by Cyber Forensics Team
Cyber Forensics Team
The Cyber Forensics team at WindowsSCOPE is composed of leading experts on Windows internals, cyber security a...
User is currently offline
on Monday, 27 June 2011
in Use Cases

With WindowsSCOPE users are able to view network activity on a computer. To see this, load a snapshot and on the left panel go to Memory View → Summary of System Activity → Open Network Sockets. This view will list all connections open on the computer at the time of the snapshot being taken. The 'Source' IP Address, 'Destination' IP Address, 'Type' (UDP/TCP), 'Process', and 'State' of the connection (only TCP) are all displayed.