Cb Connect 2018 | Power of You | Register Now


The Truth About RAM Scrapers

The Truth About RAM Scrapers Green
February 21, 2014 / Chris Lord

­With continuing concerns about retailers and their susceptibility to memory scraping malware, I thought it might be a good time to follow up our recent posts by Matt and Harry with a deeper examination of these memory-based threats, often referred to as “RAM scrapers.”

It is useful to distinguish between memory-based threats that work from outside an application by exploiting a vulnerability or opportunity elsewhere in the system, and those that work from inside an application by exploiting a vulnerability in the application itself. Memory scraping works from outside an application, so this post will focus on that threat; I’ll look at threats from inside an application in a future post.

Behind the Scenes: Protecting Process Memory

Memory scraping can be done in Windows using EnumProcesses to enumerate processes on the system looking for processes of interest by name (such as pos.exe) and using the associated PID with OpenProcess to obtain a handle. The process must be opened with PROCESS_QUERY_INFORMATION and PROCESS_VM_READ in order to access the process resources. VirtualQueryEx on the handle will obtain all memory regions and the contents can be copied and scanned from all non-image regions with ReadProcessMemory. This unique combination of functions is found in the imports of the BlackPOS/Kaptoxa malware implicated in the Target breach, and their use elaborated a recent Volatility Labs post.

If you could block the PROCESS_VM_READ right to a process, then you could prevent another process from accessing that memory—and prevent memory scraping.

Protected processes as introduced in Windows control the rights at the kernel level that can be granted to thread and process objects when opened or duplicated by user-mode processes. Unfortunately, this is an all-or-nothing deal that restricts all but a set of limited query access.

The Bit9 approach allows any right listed in the table below to be granted or denied between any pair of objects. In fact, we use this capability to enforce the principal of least privilege with applications that request all rights rather than just those that are needed and help reduce surface, not just to prevent or detect access.

Group Description Restricted Rights Examples of Affected APIs
Read Access required to retrieve, copy or duplicate certain information about a process or thread; most notably its memory, but also token information, impersonation context, exit code and priority. PROCESS_DUP_HANDLEPROCESS_VM_READPROCESS_QUERY_INFORMATIONTHREAD_GET_CONTEXTTHREAD_QUERY_INFORMATIONTHREAD_IMPERSONATE OpenProcessToken, GetExitCodeProcess, GetExitCodeThread, GetPriorityClass, GetThreadContext, IsProcessInJob, DuplicateHandle, ReadProcessMemory
Write Access required to modify certain information about a process or thread such as its memory, impersonation context, working set size, and priority. PROCESS_SET_QUOTAPROCESS_SET_INFORMATIONPROCESS_VM_OPERATIONPROCESS_VM_WRITETHREAD_SET_INFORMATIONTHREAD_DIRECT_IMPERSONATIONTHREAD_SET_THREAD_TOKEN SetProcessWorkingSetSize, SetPriorityClass, SetThreadToken, SetTokenInformation, SetProcessAffinityMask, VirtualProtectEx, WriteProcessMemory, SetThreadIdealProcessor
Control Access required to control the execution of a process or thread, including the ability to terminate or debug the process. PROCESS_CREATE_PROCESSPROCESS_CREATE_THREADPROCESS_SUSPEND_RESUMEPROCESS_TERMINATETHREAD_SUSPEND_RESUMETHREAD_TERMINATETHREAD_SET_CONTEXT SetThreadContext, SuspendThread, ResumeThread, TerminateThread, TerminateProcess, CreateProcess, Createthread, CreateRemoteThread, SuspendThread, and ResumeThread

Memory scraping locates sensitive data in an application by scanning for signs of the intended data and copying it. This works because decrypted or raw data exists temporarily in memory even when it might be stored or transmitted securely. The detection mechanisms others use to identify this type of malware look for recognizable signatures in files or registry contents, or watch for signs of its exfiltration activities. These tells are easily changed by attackers in new variants or in different strains.

A more potent alternative is to treat the above behavior as suspicious when directed at a process that harbors sensitive data. Bit9 enables you to establish perimeter alerts on the high-value processes so you can detect unauthorized attempts to read or write application memory, reverse engineer, or commandeer control by injecting threads and images into application processes. Exceptions can easily be created to ignore activity that follows the same pattern but should not generate alerts. For example, a rule like the following will cause endpoints to report an event on any unexpected access to a specific process identified by hash:

Report any attempt by a process to read the memory of a process with the SHA256 74e08f7f02ada74f3413ebda3fd06ec564f7416babca83d736524cf2f869396a unless the source process is a Windows component and all process images are signed by Microsoft.

Detection using behavioral patterns is effective for dynamic environments when you don’t want to risk interfering with legitimate activity. In the case of fixed-function systems like those used for point of sale, the same mechanisms used for detection can be used for prevention using a rule like:

Block any attempt by a process to read the memory of a process named pos.exe unless the source process is a Windows component and all process images are signed by Microsoft.

This is possible because Bit9 provides fine-grained, policy-based control over the interactions between objects in the system through declarative rules engine in the kernel and a set of built-in and user-defined production rules. In the case of process objects, each access right can be controlled individually or as part of Read, Write or Control groups (see sidebar). Each rule can include additional qualifiers such as the user, process ancestry, file signature and device type to make them as broad or narrowly targeted as necessary.

When a rule blocks all access (Read + Write + Control groups) to a specific process without qualification, the result is effectively that of a Protected Process, which was introduced with Windows Vista.

Alex Ionescu wrote about some of the problems with protected processes when they were first introduced and has since revisited the topic with an informative series of posts on how they’ve been improved in Windows 8.1 with Protected Processes Light. One of the problems with protected processes when they appeared in Windows Vista—ignoring the DRM legitimacy debate—was the lack of fine-grained control and exceptions. System software that needed to inject into running processes (such as virtualization and security) would be unable to add their components. And because the protected state was an all-or-nothing deal until Windows 8.1, such software has no choice but to completely disable the protection on a process if they want in.

In contrast, Bit9 process interactions and exceptions can be controlled with the precision required to allow what you want and deny what you don’t. And unlike protected processes, Bit9 controls work equally well on Windows XP as they do on Windows Vista and beyond.

Every version of Windows introduces new and improved security features. If you haven’t upgraded or are using software that hasn’t been updated to take advantage of the latest features (and while we’re waiting for the slow adoption of other card technologies), there are still ways to help keep your critical and high-value processes safe from the prying eyes of memory scraping malware. Bit9 memory detection and prevention can be an effective part of your defense.

TAGS: application control / memory scraping / ram scraping / Whitelisting