Content uploaded by Mohamed Alshehri
Author content
All content in this area was uploaded by Mohamed Alshehri on Sep 02, 2021
Content may be subject to copyright.
Windows Memory-Injected Malware Detection
Freeware Comparison
Mohammed Alshehri
maa7211@rit.edu
Christian Brady
chb9645@rit.edu
Jared Albert
jaa3711@rit.edu
I. INTRODUCTION
This past year has been an unprecedented time for most
organizations all over the world. The restrictions put into place
due to the international pandemic has put incredible amounts
of pressure on these groups to restructure their workplace
infrastructure to introduce or strengthen remote work initia-
tives. This unfortunately has resulted in a deadly combination
of resources meant for regular security evaluations, as well
as higher risks when creating or modifying newer, remote-
focused infrastructures with already thinned budgets.
Overall, Windows malware detection was down 12% over-
all, with 24% down from businesses [1]. This means that
overall, less evaluations and scans were performed, despite
the heavy changes many businesses had to have gone through
to accommodate pandemic restrictions.
With all the rapid changes and evolution in companies’
system infrastructure, there is now, more than ever, a need
for a comprehensive, affordable malware detection system.
The most utilized method of evasion used by malware is
through process injection [20]. Process injection involves the
manipulation of the memory used in a process to insert a
malicious piece of code to be run under the guise of a trusted
service. According to Red Canary’s 2020 Threat Detection
Report, ”Process Injection accounted for 17% of all the threats
Red Canary analyzed in 2019, affecting 35% of customer
organizations” [22].
It is nearly impossible to take into consideration every
alternative method of performing these injections. However,
thanks to these tools being either completely open-sourced,
which allows for other people or groups to add components to
these tools overtime to improve their capabilities, or adjustable
through different configurations, enumerating and building on
these tools really allows for a much more robust forensic
product.
In this paper, we compare the most commonly used open-
source process injection detection tools available to determine
which one is the most efficient in different organization
situations, in terms of comprehensive detection, steps for
configuration, and utilities for relaying discoveries. These tools
include Memhunter [12], Volatility [9], and Windows’ own
Sysmon [6]. Through this discovery process, we hope to
inform readers of the comparatively best solution among these
tools to use, as well as highlight the pitfalls these injection
detection tools might have in common.
II. BACKGROU ND
In order to understand how these injections fully utilize pro-
cess manipulation, one must first understand the components
of Windows’ processes.
A. Windows Process Structure
1) Processes: Processes in Windows systems are repre-
sented by executive process, or EPROCESS, blocks within
the system’s virtual address space. These blocks contain and
spawn its necessary threads with its ETHREAD (executive
thread) object [26]. The processes contain loaded modules,
which consist of executables and libraries of commands and
functions like DLL’s (more on these in a bit), which perform
the command’s desired purpose by interacting with the system.
Creating a process involves opening a saved image file,
usually a .exe file. This contains the initializing instructions for
the specific process, such as memory size, memory location
specifications and file permissions. The initial thread object
is then created, and run. By that initial thread, modules are
loaded into the address space, thus completing the process
and allowing the fully process to begin execution.
A process uses one or more threads at a time, meaning
the initiation and chain of commands for threads performing
system changes come from a process.
2) Threads: Threads are the actual cause of execution in
programs, performing the functions and storing return values
from these functions. A thread’s memory is allocated and
distributed by its process. The memory given to it usually
comes from the process’s address space, meaning that the
thread can be traced back to a process. [27] The thread, when
in use, uses a specified amount of resources to perform its
duty, and has several attributes that call back to its origin,
including initiation time, thread ID number, among others.
3) DLL’s: Windows systems over the decades have opti-
mized configurations to require as little customer interaction
as possible, even as far as making the majority of their systems
backwards compatible. To cut down on function redundancy
throughout different programs, and for segmented updates of
specific functions instead of entire programs, Dynamic Link
Libraries, or DLLs, were implemented. DLLs are libraries
containing specific functions that can be used simultaneously
by various programs in the system. Many are used by simple
processes, like dialog box openings, GUI maintenance and
interactions, and even thread opening and maintenance.
Since the Windows API uses many of the same functions
throughout all of its processes, instead of relying solely on var-
ious executable files with negligible differences between each
program, these functions could be subdivided into different
modules. This allowed for processes to run faster by accessing
various, short modules instead of loading larger program files.
[3]
4) VAD: For a cleaner look at the interweaving process
addresses found inside a Windows memory dump, Virtual Ad-
dress Descriptors, or VAD’s, represent the chain of processes
and libraries in memory used by a specific process [7]. The
VAD’s form a binary tree, with nodes determined by address
location. VAD’s can show the origins of specific processes
in memory, so it helps a great deal when seeing what parent
processes spawned suspicious threads or sub-processes.
Using these various attributes of each of these structures,
malicious processes can be deduced and found out by these
tools and those with trained eyes.
III. MALWAR E ANALYSIS TECHNOLOGIES
To observe the differences between various free publicly-
available memory-resident malware detection tools, and to
determine what situation each tool would be best suited for,
we performed injections on copies of a Windows 10 Education
Version system and seeing if the tools detect the injection.
The detection systems we look at include Windows’ Sysmon,
Volatility, and Memhunter.
A. Sysmon
Short for Windows’ System Monitor, Sysmon is a Windows
service and driver that stays up across system boots, moni-
toring and logging activity to the Windows Event Log. This
includes process creation and management, raw read access of
memory, network activity, and DLL and driver loads through
their signatures and hashes. [6]
Sysmon uses XML schemas as its configuration files, allow-
ing users to direct the results of Windows Event Logs to act on
any suspicious activity made by processes. It is aggressively
updated by Windows, making it the relatively most recently
updated of our three tools.
Sysmon organizes its events by EventIDs, which include
timestamps, related processes, thread attributes, and hash and
register values. This shows great potential in using Sysmon
as the backbone for an automated injection detection system.
Sysmon, sadly, is not a detection system in and of itself.
The standard Sysmon configuration definitely lacks even
the most essential detection methods, so we found the most
popular free online configuration file for Sysmon, SwiftonSe-
curity’s sysmon-config. This config file utilizes more Sysmon
functionalities, so adding this is a needed bare minimum
requirement for a Sysmon setup.
B. Volatility
Volatility is an open-source collection of memory-analysis
tools [9]. Volatility analyzes and parses through the memory
dumps of target systems. Base Volatility contains several flags
and tools that would help with raw memory analysis, including
process enumeration, open connections and socket listings,
and online hash and file signature comparisons. Volatility also
offers various open-source plugins that help add functionality,
including using results from its memory scan to perform
injection analysis from behavioral heuristics. Other plugins
can help enumerate hooks and DLLs, map out the memory
sampled, and matching and aligning offset memory [8].
Malfind, the primary malware analysis Volatility plugin,
specifically focuses on searching for traces of injected or
hidden DLL’s or code [10]. These DLL’s are considered
hidden because they do not use the CreateRemoteThread to
LoadLibrary method of injection.
It prints the attributes about memory areas it comes across,
including its location, the start and end addresses of the area,
and the dump and disassembly of the area. It can also extract
each suspicious region to a separate file [21].
C. Memhunter
An open-sourced endpoint tool that detects malware residing
in memory, Memhunter reads from a library of known
memory injection technique heuristics to evaluate processes
and detect any suspect behavior [12]. Memhunter uses live
analysis of ETW (Event Tracing for Windows) events to detect
potential code injection attacks, meaning memory dumps are
not necessary in order to analyze systems. Not having to
perform memory dumps means a significant cut in analysis
time, as there is no need to extract static memory to check for
differences in process resources.
Memhunter scans the system memory to locate specific
injection attacks. Manhunter’s binary contains scanners called
’hunters’ that check through the system’s memory for behavior
that reflect known activity recorded in each respective hunter’s
heuristics library [12].
The nine ‘hunters’ Memhunter provides include the follow-
ing heuristic activities:
1) Suspicious Threads - Searches through area of threads,
actively searching for RWX flags in the the thread’s base
address, as well as abnormal thread sizes and stranded
code in memory regions
2) Suspicious Callstack - Walks through callstack, compar-
ing current threads with callstack addresses and info on
thread, alerting on suspicious differences, like memory
size and differences in expected thread enumeration
3) Suspicious Exports - Well-known suspect exports like
ReflectiveLoader(), among others in listed in heuristics
4) Suspicious Hollowed Modules - Compares PE headers
of the current on memory processes with those on-disk,
for correct area associations
5) Suspicious Modules - Searches through module memory
areas for RWX regions
6) Suspicious Parents - Goes through VAD to search
for suspect parent processes, primarily looking at ser-
vices.exe and wininit.exe to see if any unwarranted links
exist between the two executables
7) Suspicious Regions - Searches through each process for
memory modules needed for use, and checks these areas
for wiped PE headers and other suspicious attributes
8) Suspicious Registry - Checks the registry for com-
mon persistence techniques established by malware, like
LoadAppInit DLLs, compares DLL list and their base
addresses to a saved list of suspicious DLL activity or
attributes
9) Suspicious Shellcode - Performs fuzzy matching on
committed memory for x64 or x84 prologue opcodes,
walking the remote process memory
Memhunter monitors thread creation, including locations in
memory. By doing this, the source of the possibly malicious
thread’s creation, labeled under the ‘SourceImage’ flag, is
noted and paired with the ‘TargetImage,’ if the event is flagged.
Memhunter was specifically created to be an all-
encompassing, easy to read solution. As described in the
readme.txt file in Memhunter, Memhunter was ”designed as
a replacement of memory forensic volatility plugins such as
Malfind and Hollowfind [12].”
Memhunter also has sqlite integration, Yara compatibility,
and can also directly report to Windows Event Log.
Reported info includes PID, TID, thread integrity levels,
abnormal user tokens, Group ID, Debug privileges and its
token, Thread BASE Priority, and session info, like username,
privileges, among others.
Memhunter, in order to better analyze systems, has
incorporated the Blackbone library, which allows for memory
areas and thread enumeration, as several functions in
Blackbone’s library can be used to parse and even manipulate
memory [24].
D. Minjector
Thanks to Memhunter’s open source repository, its con-
tributors added a separate injection tool called Minjector,
which contains various injection techniques to be applied to a
targeted system [25]. Using various injection methods included
in Minjector’s library, we used the Memhunter, Volatility,
and Sysmon tools to test each one’s capabilities in injection
detection.
IV. PROCESS INJECTION
A. The Injection Process
Process injections, apart from being the most common
method of evasion when installing malware, have a few
separate unique properties. Basically, modules can be written
into the address space of the target process by remote malware.
The target process itself isn’t malicious, but the call will
contain malicious instructions that the process will perform.
These specific injected processes are what the tools must figure
out. Figure 1 shows a simplified diagram of a process injection.
Matching Figure 1’s numbered steps is Figure 2, an example
of one of the injections we performed.
In order to create and designate the area to be used to
hold the malicious payload, malware can invoke either of
the VirtualAllocEx or NtAllocateVirtualMemory functions to
allocate new memory in the target. Through this process, the
injector can initiate the new memory to be read, writable,
Fig. 1. Process Injection Steps
and/or executable. The injector designates existing memory
within the target for overwriting into either one of three
sections of memory of a thread: the stack, heap, or .data
sections.
If the stack is used to base the memory allocation, it can
take up either the memory currently in use, or it can also be
written in the area beyond the TOS (top-of-stack).
If the new memory is designated before TOS, the new
memory overwrites existing stack, so the injector must take
into consideration processes, DLLs, or other executables to
better hide their suspicion movements and actions. In the case
that memory beyond TOS is allocated, the same area may be
overwritten by later functions.
In the .data sections of some DLLs have “spare allocation”
that is initialized with 0’s. An injector could possibly use this
section.
As for the heap, using a thread’s return values, an injector
can find out where in memory specific objects reside. These
objects’ addresses could be used, but the entire memory area
could be modified or destroyed as the object is changed or
moved by other functions.
When space is allocated, the path to the malicious DLL
is then written in using the WriteProcessMemory. Finally,
the malware can call any API to run the thread so the
injected code can be processed. These APIs include CreateR-
emoteThread, which is a dead ringer for process injection,
NtCreateThreadEx, or RtlCreateUserThread. To further hide
the creation of this specific thread, usually LoadLibrary is
run, which passes its address and creates the thread, making
a remote process execute the injected DLL [5].
Fig. 2. Minjector Injection Steps
B. Injection Techniques
Among the ones listed in the Minjector library, we chose
six injection techniques and tested them against our suite of
detection tools. These injections range from simply injecting
code during a process suspension to requiring the additional
Blackbone library from Memhunter’s library.
C. Injection via CreateRemoteThread()
The most basic injection in our list, it follows the funda-
mental steps outlined in the previous section.
1) First, get a thread handle from the targeted process.
2) Use VirtualAllocEx to allocate new memory space.
3) Use WriteProcessMemory to write the DLL into the new
space.
4) Get the real address of LoadLibraryW in Kernel32.dll
5) Using LoadLibraryW, use CreateRemoteThread() to
make a thread that runs the created address space for
the DLL above. (The header from LoadLibraryW can
be seen in Figure 3.)
6) Close the process handle from step 1.
Fig. 3. CreateRemoteThread() Injection
D. Injection via a ’Stealth’ CreateRemoteThread()
The major difference between the normal and this ”stealthy”
CreateRemoteThread() injection is the PE header is deleted
when the DLL is loaded directly. The malicious DLL is loaded
using LdrLoadDll instead of WriteProcessMemory(), as can
be seen in Figure 4. Clearing or adjusting the header of
the process in an injection greatly improves its avoidance of
several obvious hints of injection, but the use of CreateRe-
moteThread() in of itself is damning evidence.
Fig. 4. Stealth Injection
E. Injection via QueueUserAPC()
The following injection focuses on Asynchronous Proce-
dure Calls, or APCs. APCs queues allow threads to execute
code asynchronously. When an APC is queued to a thread,
a software interrupt occurs, and the APC function is run the
next time the thread is scheduled. When creating a thread to
support APCs, the threads have to be in the alertable state
[15].
The QueueUserAPC() function queues an APC to a thread,
meaning its a request for the thread to call the APC function.
The thread must be in alertable state, which means it must be
running under one of 5 functions: SleepEx, WaitForSingleOb-
jectEx, WaitforMulipleObjectsEx, SignalObjectAndWait, Ms-
gWaitForMultipleObjectsEx(probably RealMsgWaitForMulti-
pleObjectsEx) [14].
1) Follow steps 1-3 of CreateRemoteThread injection.
2) Enumerate the target process’ threads, marking down
each header.
3) Use QueueUserAPC() or NtQueueApcThread() on each
of the thread headers.
4) The ‘alertable’ state allows the code to be executed.
F. Suspend-Inject-Resume
This type of injection is most similar to process hollowing,
as it targets an existing, running thread, forces it into sus-
pended mode by calling SuspendThread. While the target is
in suspension, malware calls VirtualAllocEx and WriteProcess-
Memory, which allocates space in the thread for the injection.
The allocated memory is then filled with shellcode, the path
to a malicious DLL, and the returned address of LoadLibrary.
This method is somewhat risky, as suspending the thread in
the middle of a system call may cause crashing in other parts
of the system.
1) Write code to memory using a write primitive (Virtu-
alAllocEX with WriteProcessMemory)
2) Execute code using SetThreadContext, as thread needs
to be suspended, then resumed.
3) Set the instruction pointer to point to the payload code.
4) Initialize the thread, allowing the code to be read and
processed by the pointer.
G. Image Mapping
One of the injections is labelled as “DLL Injection via
Image Mapping.” This technique is more commonly referred to
as the Reflective DLL injection. Both names refer to mapping
a DLL from an image from memory instead of the disk. This
allows the library to reflectively load itself using a PE loader
that allows it to minimize interactions with the host system
and process, as well as determine interactions with the host
[19]. The injection command is shown in Figure 2, with the
resulting thread created in Figure 5.
1) The library you want to inject must already be written
into the address space of the host
2) The library’s runtime must be consistent with previous
limits(ie. It cannot waste any extra time resolving im-
ported libraries, misalignment with memory)
3) Execute the thread to the library’s ReflectiveLoader,
which is an exported function found in its export table
4) ReflectiveLoader then calculates its current image loca-
tion to parse headers in future use.
Fig. 5. Image Mapping Injection
5) Execute the thread to the library’s ReflectiveLoader,
which is an exported function found in its export table
6) ReflectiveLoader parses through the host’s processes
kernel32.dll export table to calculate addresses
ofLoadLibraryA,GetProcAddress and VirtualAlloc.
7) ReflectiveLoader then allocates memory area to load its
own image, to be correctly located later on.
8) Library’s headers and sections are loaded to the area
from step 6
9) ReflectiveLoader then process the copy of its import
table in the new image to load and resolve any imports
and libraries and their addresses
10) ReflectiveLoader then processes the copy’s relocation
table
11) The copied image’s entry point function, DllMain, is run
with the flag DLL PROCESS ATTACH. After this, the
library has been loaded into memory.
12) The initial thread that created it is terminated, or the
shellcode that loaded it is returned.
[18]
V. EXPERIMENT DE SI GN A ND RE SU LTS
Using various injection methods included in Minjector Tool,
we used the Memhunter, Volatility, and Sysmon tools to test
each one’s capabilities in injection detection. We deploy these
injections into copies of a virtual machine of Windows 10
Educational Version. From our results, we are looking to
make comparisons between each tool, ranging from ease of
installation to detection effectiveness. These comparisons will
help us in choosing the best of the three tools.
A. Results
1) Sysmon: Sysmon’s output comes in either the Event
Viewer GUI (Figure 7) or in specific Sysmon logs. Although
reflecting vital process attributes, there is not too much we can
discern from its output.
As you can see from Figure 6, and as stated earlier, default
Sysmon, with no changes to the configuration, was the most
Fig. 6. Results of Injection Scans
Fig. 7. Sysmon Output
unsuccessful of the group, with no way to actually detect any
of the injections.
Even with the addition of the SwiftOnSecurity/Sysmon-
config file and even our own customization to the schema,
Sysmon was still lacking in detection, severely lacking in
overall effectiveness and ease of use. In order to even use a
competent version of Sysmon, as compared to the other tools,
one has to put in the time to learn and properly format their
own configuration file, destroying any semblance of plug and
play.
2) Memhunter: Memhunter, as expected, was able to find
all of the injections. An excellent possible future experiment
would be to find a new repository or group of injections
from an outside party; that way, the injections do not come
from a related source, as it may not push the tool to perform
techniques different from the one the creator made.
Fig. 8. Memhunter Output
3) Volatility Malfind: Malfind’s output does not display
the same information that the other two tools did. This is
because a lot of these attributes can be seen using the other
commands Volatility has, including psscan, among other. The
malfind scan is specifically made to show where, in memory,
the specific suspicious area is, using its VAD, as seen in Figure
9. It also directly outputs the disassembly of the suspicious
code, allowing for a user to diagnose the issue, if any, almost
immediately.
Volatility’s performance with the injections proves that it is
still a great tool to use when dealing with memory forensic
situations in general, not only dealing with injection detection.
Fig. 9. Volatility’s Malfind Output
B. Testing Issues
Initially, some of our scans were not compatible with the
Windows 10 system, which was a Win10x64 17763 system
with 8 GBs of RAM. Initially, we theorized that our instal-
lation for the remaining tool, Volatility, was not configured
correctly. Initially, we were investigating a .vmem dump of
the Windows 10 machine and encountered no issues with the
other scans.
However, we soon discovered that the machine the image
had been dumped by might have led to the issue, as the
Windows image was acquired by manually copying a snapshot
from ESXi VMware hypervisor. We tried to use vmss2core
on the copied snapshot to convert it from a vmem to a raw
dump. As it turned out, vmss2core was not compatible with
Win10x64 17763 Windows systems copied from ESXi servers
[23], which can be seen in Figure 10.
Fig. 10. Volatility Image Error
Because of this, we were forced to remake the Windows 10
image as a .raw image dump. With all of the testing performed
again, the same results were found in the initial scans of the
.vmem image as they were in the new .raw file.
Because of this, our interest was piqued into possible
future research surrounding the integrity and readability of
converted forensic images, particularly by different software
like Vmss2core, and reliability of using VMware snapshots
as digital forensics collecting tool, and the seeing how this
would affect forensic investigations performed with our suite
of tools.
VI. CONCLUSIONS
In general, one must remember that these tools are detection
tools, not preventative. Issues that come up should be detected
and reported through logs, but any additional info about
possible sources of the malware is too advanced and should
be assessed by security administrators.
A. Volatility
Volatility is operable from almost every system, meaning
performing memory scans on an individual dump can be done
from almost anywhere. This allows for a scriptable, automated
mass scan across several memory samples. The downside,
however, is extracting a memory dump out of every system.
Unfortunately, Malfind, as discussed by Block et al., has a
glaring issue, in that it will not detect ”unnecessary” memory
regions, allowing for those crafty enough to partition virtual
memory in an unrelated area of memory with RWX permis-
sions to slip in the injection malware in those areas [11]. For
the purposes of our experimentation and results, we cannot
rank this the highest tool with such a glaring issue.
We have been using Volatility 2 during the extent of this
project, so we do realize that Volatility 3 will soon overtake
Volatility 2’s popularity and position. However, even with our
injection test, we do acknowledge Volatility 2 as an incredibly
useful and completed tool, especially with Volatility 3 still
being worked on by the community today.
B. Sysmon
Unfortunately, even with the direct commanding of Win-
dows Event Log reports, Sysmon did fail to detect every
malware trace on the systems, making it the clear loser in
this situation.
The lack of a comprehensive Sysmon configuration schema
defeats the purpose of using Sysmon. SwiftOnSecurity’s con-
figuration schema is, as said before, the bare minimum to even
rate it somewhat comparable to the other tools. Unless Sysmon
is configured to log every remote thread creation event, it
would be hard to detect all injection types and their related
processes.
Sysmon shows great potential, but only to those who are
patient enough to know how to work and take advantage of
it, not to those who need a quick and comprehensive memory
forensic detection system.
C. Memhunter
Memhunter seems like the total package, as it passed our
injection test with flying colors and was not particularly
difficult to set up for.
Unfortunately, as a detection system across several systems,
it has several flaws that hinder its great performance.
Memhunter can only be run locally, sending out the results
of its scans to stdout. This means a separate script will have
to be written in order to output all of its scan results into a
separate report format.
This also means that comparing the reports between multi-
ple systems being scanned is only possible through separate in-
stances of Memhunter and sifting/comparing reports between
each machine.
Therefore, Memhunter would be a great attribute for indi-
vidual system forensics, not for network or enterprise-wide
simultaneous investigations.
Fig. 11. Differences between Volatility, Sysmon, and Memhunter
VII. FUTURE WORK
Building off our research in finding the best tool to use
for Windows memory malware, we have not used all possible
schema or configurations for all of our tools. The injections we
used were also developed by the same creators of Memhunter,
so the use of outside test injections to compare the three seems
to be the next logical step.
Volatility3 has new attributes and standardizes its profile
matching, so someone does not have to wait for an imgscan
result to perform a scan. Testing a wider gamut of process
injections against various different Windows systems could
definitely place Volatility at an advantage above the other tools.
Developing a comprehensive Sysmon schema would defi-
nitely add to its capabilities, although doing so would require
a rather intimate knowledge of the operating system being
worked on.
REFERENCES
[1] Liu, Shanhong. “Computer Operating Systems Market Share 2012-
2020.” Statista, 14 Oct. 2020, www.statista.com/statistics/268237/global-
market-share-held-by-operating-systems-since-2009/.
[2] Kujawa, Adam. Malwarebytes 2021 State of Malware. Mal-
warebytes Inc., Feb. 2021, resources.malwarebytes.com/files/2021/02
/MWB StateOfMalwareReport2021.pdf.
[3] Deland-Han. “Dynamic Link Library (DLL) - Windows Client.”
Dynamic Link Library (DLL) - Windows Client — Microsoft
Docs, 22 Sept. 2020, docs.microsoft.com/en-us/troubleshoot/windows-
client/deployment/dynamic-link-library.
[4] “Process Injection: Dynamic-Link Library Injection.” Process Injection:
Dynamic-Link Library Injection, Sub-Technique T1055.001 - Enterprise
— MITRE ATT&CK®, attack.mitre.org/techniques/T1055/001/.
[5] Hosseini, Ashkan. “Ten Process Injection Techniques: A Technical
Survey of Common and Trending Process Injection Techniques.”
Elastic Blog, 28 Jan. 2020, www.elastic.co/blog/ten-process-injection-
techniques-technical-survey-common-and-trending-process.
[6] Markruss. “Sysmon - Windows Sysinternals.” Sysmon -
Windows Sysinternals — Microsoft Docs, docs.microsoft.com/en-
us/sysinternals/downloads/sysmon.
[7] Brendan Dolan-Gavitt, ”The VAD tree: A process-eye view of physical
memory.” Digital Investigation, Volume 4, Supplement, 2007, Pages 62-
64, ISSN 1742-2876, https://doi.org/10.1016/j.diin.2007.06.008.
[8] SwiftOnSecurity/sysmon-config. (n.d.). GitHub. Retrieved March 3,
2021, from https://github.com/SwiftOnSecurity/sysmon-config
[9] Volatility Repository (n.d.). GitHub.
https://github.com/volatilityfoundation/volatility/wiki
[10] Volatilityfoundation. “Malfind ReadMe.” GitHub,
github.com/volatilityfoundation/volatility/wiki/Command-Reference-
Mal#malfind.
[11] Block, Frank Dewald, Andreas. (2019). Windows Memory
Forensics: Detecting (Un)Intentionally Hidden Injected Code by
Examining Page Table Entries. Digital Investigation. 29. S3-S12.
https://dfrws.org/wp-content/uploads/2019/06/2019 USA paper-
windows memory forensics detecting unintentionally hidden injected
code by examining page table entries.pdf
[12] memhunter Repository. (n.d.). GitHub. Retrieved March 3, 2021, from
https://github.com/marcosd4h/memhunter.
[13] Blackhat 2019 Process Injection Techniques. i.blackhat.com/USA-
19/Thursday/us-19-Kotler-Process-Injection-Techniques-Gotta-Catch-
Them-All-wp.pdf.
[14] “APC Queue Code Injection.” Red Teaming Experiments,
www.ired.team/offensive-security/code-injection-process-injection/apc-
queue-code-injection.
[15] Mcleanbyron. “Asynchronous Procedure Calls - Win32 Apps.”
Win32 Apps — Microsoft Docs, docs.microsoft.com/en-
us/windows/win32/sync/asynchronous-procedure-calls.
[16] Wolters, Mark. War Room, 17 Mar. 2015, warroom.rsmus.com/dll-
injection-part-1-setwindowshookex/.
[17] Hickeys. “Hooks Overview - Win32 Apps.” Win32 Apps — Microsoft
Docs, docs.microsoft.com/en-us/windows/win32/winmsg/about-hooks.
[18] “Reflective DLL Injection.” Red Teaming Experiments,
www.ired.team/offensive-security/code-injection-process-
injection/reflective-dll-injection.
[19] Stephenfewer. “Stephenfewer/ReflectiveDLLInjection.” GitHub,
github.com/stephenfewer/ReflectiveDLLInjection.
[20] “MITRE ATTamp;CK® Technique T1055: Process Injection.”
Red Canary, 22 May 2020, redcanary.com/threat-detection-
report/techniques/process-injection/.
[21] Case, Andrew. Automating Detection of Known Malware
through Memory Forensics, 2 Aug. 2016, volatility-
labs.blogspot.com/2016/08/automating-detection-of-known-
malware.html.
[22] “Process Injection: a Primer.” Red Canary, 19 Jan. 2021,
redcanary.com/blog/process-injection-primer/.
[23] ”vmss2core Tool Bugs”, VMWare, 17 Mar. 2021,
https://flings.vmware.com/vmss2core/bugs/864
[24] ”Blackbone Repository” . (n.d.). GitHub. Retrieved March 3, 2021, from
https://github.com/DarthTon/Blackbone.
[25] ”minjector library” . (n.d.). GitHub. Retrieved March 3, 2021, from
https://github.com/marcosd4h/memhunter/tree/master/utilities/minjector
[26] “Processes, Threads, and Jobs in the Windows Op-
erating System.” Processes, Threads, and Jobs in the
Windows Operating System — Microsoft Press Store,
www.microsoftpressstore.com/articles/article.aspx?p=2233328.
[27] “Pushing the Limits of Windows: Processes and Threads.”
TECHCOMMUNITY.MICROSOFT.COM, 27 June 2019,
techcommunity.microsoft.com/t5/windows-blog-archive/pushing-the-
limits-of-windows-processes-and-threads/ba-p/723824.