Posts
It’s standard procedure to use obfuscation methods in order to hide, among the system/user processes, the process associated with the malware. Common RAM analyses split in two ways of searching processes in the image memory:
- List-walking: which traverses the kernel's linked list of process data structures;
- Scanning: which does a sweep over memory, looking for byte patterns that match the data found in a process data structure.
The most common procedure is the use of the DKOM (Direct Kernel Object Model) technique presented also at the Black Hat.
Information present in the memory can be generally split in two categories: data and codes. Data refers to bytes that are not executed. For example, it could be data structures directly linked to the kernel functioning of the system or data of an open file. Data is usually stored in parts called heap, stack and pool. Codes refer to executable ‘commands’ necessary in order for the processor to end its task. Current rootkits can be ‘invisible’ and alter the content of the memory in order to change the behaviour of the operating system or the ways in which data is presented to the user. The operation which controls the content of the memory is called “memory patching”.
The term ‘ring’ is used to refer to the privilege level when an application is run. The term “ring 0” identifies running processes in kernel mode and “ring 3” refers to application in “user mode” such as browser, memo pad, etc . With “ring 0” the processor gets access to all registers and the entire system memory; with “ring 3” access is allowed solely to those memory parts used in “user mode”. Obviously the interest area for the rootkit is “ring 0”. Here is a practical example: In case you wish to obtain the list of processes running on one's Windows system. The first step is to open the Task Manager. This system application however, operates in user mode although running the code 'kernel' mode and retrieving the list of running processes. For this type of activity, the Windows Task Manager invokes a feature called NTQuerySystemInformationpresent in the NTDLL.DLL. A routine that operates in kernel mode receives the request and draws on an appropriate kernel structure called System Service Descriptor Table (SSDT). Every time the system interfaces with the kernel in order to run operations requested by applications or through the use of the shell, we could have to deal with a possible point of attack that a rootkit can use in order to alter the normal information flow and thus undermine the correct functioning of Windows. Before invoking a feature able to interface with the kernel of the operating system, the feature has to be imported by the application about to use it. This means that the library(file DLL) with the feature has to be uploaded in the memory space used by the application and added to a special table called Import Address Table. This method adds a new point of failure that the rootkit can take advantage of. Another method widely used by rootkit developers in order to alter the running procedure of the code in user mode is often called inline (function) patching or inserting a trampoline. In this case, the rootkit modifies the first bytes that characterize the feature; it is thus able to filter recovered data, going out of the feature. The possibilities are infinite: the rootkit could for example remove the file from a list of files into a data folder. It is thus possible to hide from the operating system and the installed applications files created ad-hoc linked to the rootkit functioning and other malware. The API NtQueryDirectoryFile is often criticised precisely for this peculiarity of rendering the list of files and folders stored in any directory on the disk.
The DKOM (Direct Kernel Object Manipulation)opened the way to the development of new rootkits that use this technique in order to hide operating processes in user mode altering the objects in kernel. One can take advantage of the kernel to hide not only processes but also peripheral drivers and network ports and run processes with higher user privileges.
In order to understand DKOM it is necessary to describe a Windows feature. The 'user mode' processes are governed by objects that operate in kernel mode known as “executive process blocks” (”EPROCESS blocks“). A EPROCESS block is a structure, stored in memory, that contains information on a specific process in 'user mode'. EPROCESS structures are organized in lists connected twice: every EPROCESS structure points to another process that contains reference (pointers) both to the following and the previous EPROCESS structure. Once the rootkit is able to identify pointers, it is easy to include them in a continuous cycle (loop) until a EPROCESS structure referring to the process you wish to hide or modify is identified. At this point, the rootkit will rearrange the distribution of pointers towards previous and following EPROCESS structures in order to 'disconnect' the hiding process from the respective EPROCESS block.
Although this technique allows to hide processes it is obvious how a low level scanning of the RAM memory searching for the EPROCESS structure could easily show hidden structures also. That's because the entire search highlights the presence of a ‘magic’ value that identifies the presence of the EPROCESS structure. The value looked for is \x03\x00\x1b\x00. This method is used in the Volatility tool through the psscan2 option. The tool makes a bruteforce on the memory under analysis searching for the pattern described. Jesse Kornblum and others have raised various questions about the need not to alter the header of the structure and on the possibility that such a modification may compromise the execution of the process. The answer was negative. The technique that reminds the “Better Magic throught fuzzing” was introduced in order to improve the detection technique of hidden. Although it may not appear appropriate the method consists of the arbitrary modification of the EPROCESS structure and the monitoring of the behaviour the system has. Fuzzing may be summed up as follows:
Once tests were over, it was possible to identify a series of patterns that have to be complete for the correct execution of the process. This approach presents various disadvantages that have to do with the operating system on which it is applied. These tests are actually repeated for the various operating systems supported by the analysis tool; especially for the 64bit systems. The above described complications have redirected investigators towards analyzing the different components involved during the execution of the process with particular attention to the connection between them. Particular interest is shown to the following:
- Thread;
- File handles.
A process is made up of different components such as: threads, handles, DLLs and other structures. As anticipated, interest is focused on threads. Every thread element is associated with a stack, operates inside that part of memory associated with the process and can interact with other threads. All threads are managed by Windows Sheduler which keeps a list of double pointers of the threads present, for each priority level. Going backwards, we note that there is inside the Windows Scheduler a list of running threads, each thread referring to the the ETHREAD structure and each ETHREAD structure refers to the EPROCESS structure. A similar analysis can be carried out for the management of the handles files; the kernel maintains a list of open files and each handle file keeps a reference to a EPROCESS file. Besides these elements (thread and file handles) there are similar analyses with open connections for example; it is thus difficult for an attacker to disguise all reference to the EPROCESS structure.
No tools combine the use of the two techniques shown: “magic” value and kernel object; however with the introduction of an add-on inside the Volatility framework it is possible to enact the first process discovery method.
Therefore, there are 51 fields inside the structure of a process that can be arbitrarily modified included those currently in use in order to find hidden processes. There are however data parts that can not be modified without causing a system crash and the end of the active process. From this analysis a new add-on called “psscan3” was created for the Volatily framework. The script considers solely the fields considered robust for the discovery phase of hidden processes.
One of the most valued features is the object of several famous publications “SIFT Workstation 2.0: SANS Investigative Forensic Toolkit" written by Russ McRee, (GCIH, GCFA, GPEN, CISSP, team leader and senior security analyst for Microsoft's Online Services Security Incident Management team) is the Windows Memory Analysis.Thanks to this new add-on. Thanks to the new “psscan3” script it is possible to see the setbacks of the previous “psscan2” and the process analysis based on new robust fields is introduced.
Here below is the output of the tests run in laboratory with an image example supplied by http://amnesia.gtisc.gatech.edu/~moyix/ds_fuzz_hidden_proc.img.bz2 where it is possible to see how the analysis of active processes with the psscan script and psscan does not detect the “network_listene process.
Very Very Thanks to Mr. Russ McRee. Senior Security analyst for the Microsoft's online security Team.
Regards
gurbinder sharma
No comments:
Post a Comment