In the previous article, we discussed some important GUI objects like session, window stations, and desktops. As we saw earlier memory forensics of GUI objects reveal a lot of important information. In this article, we will take a look at other important GUI objects such as Clipboard, Windows, Atoms and hooks (Message and Event).

Clipboard

We saw in the previous article how to detect the presence of clipboard activity over RDP (Remember rdcplip.exe. Anyone? Well, now we will see how to extract clipboard data itself. Very important information such as passwords can be recovered from Clipboard, but it depends a lot on when the memory image has been acquired and how much clipboards is still present in RAM. There are two structures available to understand clipboard data:

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

• tagCLIP: It defines the clipboard data format and a handle to tagCLIPDATA
• tagCLIPDATA: This contains the actual Clipboard data.

Now we can parse these structures using Volatility plugin 'clipboard.' This plugin will extract clipboard data from all sessions and all desktops.

Windows

This is a very important data structure and can reveal a lot of information. Windows contain items like scrollbars, buttons, etc. Windows has a data structure tagWND

Some of the important members are:

• Style: a combination of flags to display characteristics of the window such as WS_VISIBLE.
• strName: Name of window
• lpfnWndProc: window procedure function located in the respective class.

This data structure can be parsed with Volatility's plugin 'windows.' Below is a snipped screenshot for the Windows plugin.

Notice that the second window has no name and also not visible.

We can also see the parent-child relationship between windows using another plugin known as WinTree.

We can also use Volatility's screenshot plugin to draw the state of dashboard during capture. This plugin takes coordinates from tagWND structure and draws using Python Imaging Library. For example

As we can see above, there are a lot of desktop screenshots available, but most of them will be empty. Below is a screenshot for one of the active user's session 2. It is from session_2.WinSta0.Default. It makes sense because only in WinSta0 a window is shown.

Atom and Atom Tables

Processes share data between each other. Atoms are strings shared between them in the same session. To shared strings, processes use Atom tables. It works like one process share the strings by adding an atom to atoms tables which are retrieved by other processes. They are represented using structures like _RTL_ATOM_TABLE and _RTL_ATOM_TABLE_ENTRY.

Important parameters from above two structures are:

• Name: Name of an atom in strings.
• Atom: This is an integer value returned whenever an atom is added. It is also used as an index into atom table to locate a respective string.
• ReferenceCount: Increases/Decreases upon atom addition/deletion.

We can parse these structures using Volatility's plugin named atomscan. Below is a screenshot of atomscan plugin in action on Stuxnet image.

We can see that the string AFX64c313 which is used by Stuxnet to create a new window of the same name using CreateWindowEx.

Look out for blank Atom name as a potential malicious sharing by a process. Also, these days' atoms are being used by malware authors as the new indicator that a particular system has been infected similar to what we known as mutexes. But since mutex techniques are old, and there are known plugin's to extract known mutexes from images, atoms can bypass that and can be used to check whether the system has been infected or not.

Hooks

Now we will discuss two types of hooks that happen in windows all the time: message hooks and event hooks.

Message Hooks

Since processes share messages between them, message hooks as the name suggest can hook the window message before they can be delivered to the target process/window which means that messages shared between 2 processes can be intercepted. Keyboard snooping is a known example of message hooks where all the keyboard messages will be hooked and provided to some other application. This also has a structure named tagHOOK.

Some of the important parameters are:

• rpdesk: Tells the desktop where the hook is set.
• offPfn: An RVA to hook procedure.
• Ihmod: It is an index to an array of atoms, and its value should be read by translating it into an atom and finding atom name.
• ptiHooked: Name of hooked thread
• head: Owing process

This can be parsed using Volatility's plugin named messagehooks. Below is a snipped screenshot of it.

We can see that hook is Global to WinSta0 under session 0.It is gathered from tagDESKTOP structure (Refer to the previous part of this article). Since Thread is any, it means that any threads running in WinSta0 can be intercepted. In module parameter, the usual name of intercepting process/dll is mentioned (if any), and Procedure is the function offset within the hooking module.

Event Hooks

Like message, events are also passed in windows on a regular basis for example when you scroll a window an event is fired up known as EVENT_SYSTEM_SCROLLSTART. As discussed in message hooks this also works like hooking a DLL in another process. Event hooks are installed by calling SetWinEventHook. It also has a structure tagEVENTHOOK. We can parse this structure using Volatility's plugin eventhooks

Some important parameters to understand here: eventMin and eventMax apply to lowest and highest system event that the hook applies to. Here the hook is from MENU start and stop operations. Again ihmod is an index to an array of atoms. A value of -1 means that the procedure at offPfn value 0xf6264 is located inside the hooking process.

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

So in this article we have looked at what can we retrieved from GUI objects like clipboards, windows, hooks (message and event) while doing memory forensics