RECOGNISATION OF HIDDEN INJECTED CODE THROUGH PAGE TABLE

ENTRIES
Submitted by
M.SANDEEP (191711149)

In partial fulfillment for the completion of the

ASSIGNMENT-1

DEPARTMENT OF COMPUTR SCIENCE ENGINEERING

SAVEETHA SCHOOL OF ENGINEERING

SAVEETHA INSTITUTE OF MEDICAL AND TECHNICAL SCIENCES ,

CHENNAI – 602 105

February- 2020
Name :M.Sandeep
RegNo: 191711149
Class: III CSE
Subject Code: CSA5201
Subject Name: Cyber Forensics and Information Security
Course Faculty: Dr.P.Sriramya

Rubrics for Assignment 1

Problem Understanding & Literature Survey - 100 Marks

Description Total Marks MARKS

1,Problem Understanding 60 Marks
1.1Problem Identification 20 Marks
Conceptual Understanding 10
Relevance of Problem 10
1.2 Problem Specification 20 Marks
Problem Definition 8
Objectives 8
Justification 4
1.3 Problem Solving Strategies 20 Marks
Methodology 10
Constraints & Metrics 10
2.Literature Survey 40 Marks
References (Min 10) from reputed Journals/ Transaction
Reference Sources (10*2) 20
Presentation Format (10*2) 20
Total 100 Marks

Faculty
 RECOGNISATION OF HIDDEN INJECTED CODE THROUGH
PAGE TABLE ENTRIES

Problem Understanding
1.1Problem Identification

1.1.1: Conceptual Understanding

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.

1.1.2: Relevance of Problem

Code injection techniques

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.

1.2 Problem Specification

1.2.1: Problem Definition

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.

1.2.2: Objectives
our approach to implement in a plugin for the memory forensic framework
Rekall, which automatically reports any memory region containing executable pages, and
evaluate it against own implementations of different hiding techniques, as well as against real-
world malware samples.

we introduce a novel approach to reveal all executable pages that are of potential
interest for an investigator for a given user space process, despite the hiding techniques covered
in this paper.

Ignored are only yet not allocated memory pages and unmodified pages of
mapped image files (loaded executables and DLLs), as these don't contain any injected code.

In order to retrieve the actual executable state of a page and to differentiate yet
not allocated memory from currently inaccessible memory, we examine the Page Table Entries
which we enumerate via the paging structures, instead of the VADS, as it is faster and more
reliable.
 1.2.3: Justification
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.

1.3 Problem Solving Strategies

1.3.1: Methodology

Volatility and Rekall's malfind plugin examines the protection field of

VADs in order to identify injected code. When a VAD has, besides a few other criteria, a
specific protection that includes the WRITE and EXECUTE rights, malfind will identify this
VAD as potentially malicious and report it. That means, all VADs without these rights are not
considered by this plugin. the VAD's protection field only contains the initial protection, set
during its allocation. So a VAD, with a specific protection can contain pages with differing
protections.

code from malfind and other plugins relying on the protection field, the
attacker just has to allocate the memory initially with a pro-tection without the WRITE or
EXECUTE right and later on, add this right to the pages containing the malicious code. As an
alternative, malware can also use an already existing VAD, without the WRITE or EXECUTE
right, and inject its code in an unused area while adding these rights to the corresponding
page(s). Because the WRITE right is only required as long as code needs to be written, the final
page protection does not require this right at all. There is one further scenario: Injected code can
be hidden from malfind by using shared memory with a protection of EXECU-
TE_WRITECOPY , as it is explicitly omitted by the plugin. These hiding techniques, except for
the EXECUTE_WRITE-COPY trick, also work for hashtest.
 The other way to hide injected code is to make it unavailable, from a
memory forensics perspective. As paged out pages are not present in RAM anymore but only in
the pagefile(s), they are per default not part of a memory dump. The problem with plugins such
as malfind and hashtest occurs when they try to access the data behind an executable page.
malfind on the one hand wants to ignore empty pages, as there is nothing to investigate, and
hence does not report a VAD at all, if all pages appear empty. hashtest's purpose on the other
hand is to compare memory pages and hence is not interested in unavailable memory. Since
both, an actual empty page and a paged out page that might contain malicious content, appear to
malfind's internal check for empty pages as empty, a VAD with e.g. EXECUTE_READWRITE
protection is not re-ported by malfind if all pages are paged out. hashtest's output shows the
VAD in this case in its output, but reports that no page for that VAD is executable.

Paging out pages can for example be triggered manually with the
SetProcessWorkingSetSize API which allows to set the minimum and maximum working set
size of a given process and if both values are set to 1, “removes as many pages as possible from
the working set of the specified process”. The result from a successful function call is, for private
pages, typically first, a PTE state change from hardware to transition, and afterwards to pagefile
state: The pages are written to the pagefile. While the change from transition to pagefile can
sometimes take some time, it is possible to accelerate this process by allocating and accessing
new memory.

This hiding might, however, also happen unintentionally (without any assistance
by the malware). When the Operating System e.g. requires physical pages for new processes and
the pages containing malicious code haven't been accessed lately, they can get paged out. This
automatic and the manual hiding works for both, private and shared memory and hence can also
be used to hide modified mapped image files from hashtest (it is, however, not perfectly reliable
as the Windows Operating System decides if and when it writes pages to the pagefile). While
Rekall supports the integration of pagefiles and hence can prevent this hiding tech-nique,
Volatility does not.
1.3.2: Constraints & Metrics

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 .

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.

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.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. With enterprise grade access control and auditing features built in, the Rekall
Agent is suitable to be deployed in small to large scale enterprises to provide unprecedented
visibility of endpoint security, and collection and preservation of volatile endpoint evidence.
Rekall Agent can be downloaded from GitHub.Rekall's approach to memory analysis is unique -
Rekall leverages exact debugging information provided by the operating system vendors to
precisely locate significant kernel data structures. While other tools rely on heuristics and
signatures, Rekall aims to be the most stable and reliable memory analysis framework.Rekall
maintains the largest public profile repository for many operating system versions.
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
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 arte
facts, it has not been taking into account the full picture. Previous research has focused almost
exclusively on the data the operating system itself is using, not the data of 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.
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.
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/