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.
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.
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.
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:
- Found a hidden module listed in WindowsSCOPE. We noted several strings in this module that made references to Vanquish, code injection, replacing APIs, etc.
- Found a function exported from the hidden module with “FindNexFile” in the name
- Knowing that “FindNextFile” is normally an export of Kernel32.dll, we chose to look at the code for this function
- 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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
When a program is importing a function from a DLL, the function can be found in the program's import address table. Similarly, when a DLL is exporting a function for other programs to use it will be found in it's export address table.