On Challenges in Verifying Trusted Executable Files in Memory Forensics

Daniel Uroz, Ricardo J. Rodríguez∗

Dept. of Computer Science and Systems Engineering,
University of Zaragoza, Spain

Abstract
Memory forensics is a fundamental step in any security incident response process, especially in computer systems where malware
may be present. The memory of the system is acquired and then analyzed, looking for facts about the security incident. To remain
stealthy and undetected in computer systems, malware are abusing the code signing technology, which helps to establish trust in
computer software. Intuitively, a memory forensic analyst can think of code signing as a preliminary step to prioritize the list of
processes to analyze. However, a memory dump does not contain an exact copy of an executable file (the file as stored in disk)
and thus code signing may be useless in this context. In this paper, we investigate the limitations that memory forensics imposes
to the digital signature verification process of Windows PE signed files obtained from a memory dump. These limitations are data
incompleteness, data changes caused by relocation, catalog-signed files, and executable file and process inconsistencies. We also
discuss solutions to these limitations. Moreover, we have developed a Volatility plugin named sigcheck that recovers executable
files from a memory dump and computes its digital signature (if feasible). We tested it on Windows 7 x86 and x64 memory dumps.
Our experiments showed that the success rate is low, especially when the memory is acquired from a system that has been running
for a long time.
Keywords: memory forensics, Authenticode, digital signature verification, code signing, Volatility

1. Introduction memory dump can then be taken offsite to analyze it with ded-
icated software such as Volatility (Walters and Petroni, 2007),
A common kind of security incident is caused by the pres- searching for facts about the security incident.
ence of malicious software (malware) in a system. As part A memory dump contains tons of data that might be of inter-
of a security incident response process, computer and network est for analysis. Among other things, it contains a snapshot of
forensics becomes a fundamental step during the detection and the processes in execution, as well as other system information
analysis stage. Anomalous or unauthorized activity performed such as logged users, open files, or open network connections
by malware in a compromised system can be detected through at the time of memory acquisition. Note that the memory state
the analysis of both the device drive and the memory of the can be inconsistent if it was acquired in a live system, since the
system. Disk forensics is the part of forensics focused on the system itself evolves over time and system objects might be cre-
analysis of device drives. On the other hand, memory forensics ated or destroyed during the acquisition process. To assess the
focuses on the analysis of the data contained in the memory of reliability of analysis results, the use of the temporal dimension
the system under study (Ligh et al., 2014). in memory forensics has been recently proposed (Pagani et al.,
Although we normally have both possibilities, there are situ- 2019).
ations where the access to the physical device drives is difficult Code signing helps to establish trust in computer software,
to accomplish (for instance, in Cloud computing). Furthermore, since it allows to authenticate the software publisher and to
the current storage capacity in disk devices make the analysis guarantee code integrity through the validation of the digital
of memory content (in the order of magnitude of gigabytes) a signature shipped within the software (Parno et al., 2010). Sev-
more affordable task that the analysis of disk content (in the eral operating systems rely on code signing to warn the users
order of magnitude of terabytes), as well as facilitate the ini- about the potentially harmful actions that a piece of software
tial triage. Considering these facts, in this paper we focus on may perform. For instance, the execution of a properly signed
memory forensics. application in Windows avoids any alert box informing the user
Memory forensics is usually carried out capturing the cur- about the possible harmful consequences of its execution. Un-
rent state of the system’s memory and dumping it into disk as der this premise, malware developers use digital signatures to
a snapshot file. This file is also known as memory dump. A deceive users to execute their malware and thus compromise
their systems, thus subverting the trust in digitally signed soft-
ware.
∗ Corresponding
author Although the use of digital signatures in malware is not a
Email address: [email protected] (Ricardo J. Rodríguez) growing trend (Ugarte-Pedrero et al., 2019; Rivera et al., 2019),
Preprint submitted to DFRWS EU 2020 January 18, 2020
there are documented cases of signed malware samples in the 2. Previous Concepts
wild (such as Stuxnet (Langner, 2011), Duqu, or Flame, to
name a few). Malware developers use trusted certificates that In this section, we briefly describe first the Microsoft Au-
were either compromised or issued directly to them to sign their thenticode code-signing technology and then we explain the in-
software. As the primary defense against these threats, we rely ternal structures used by the Windows operating system (OS) to
mainly on the revocation process of the abused certificates done represent files.
by the certification authorities (CAs).
Intuitively, a forensic analyst can think of code signing as 2.1. Microsoft Authenticode
a preliminary step to prioritize the list of suspicious processes Microsoft Authenticode is the code-signing standard used by
that need further analysis. The rationale for this thought is Windows to digitally sign files that adopt the Windows portable
correct, but unfortunately is not very fruitful when inspecting executable (PE) format (Microsoft Corporation, 2008), which
a memory dump: a process is an inaccurate representation of includes executables (files with extension .exe), dynamically
the executable files1 in memory, since parts of the binary code loaded libraries (.dll), and drivers (.sys), among other files.
may be paged out of memory or may change at acquisition Based on Public-Key Cryptography Standard (PKCS)
time (Case and Richard, 2017). Furthermore, software defenses #7 (Kaliski, 1998) and X.509 version 3 certificates (code-
such as address space layout randomization (Bhatkar et al., signing certificates issued by certificate authorities), it allows
2003; PaX Team) or position-independent code may change the to bind an Authenticode-signed binary to the identity of a soft-
memory references of certain binary code instructions. But, to ware publisher and to guarantee the integrity of the file content.
what extent can these issues negatively affect the signature com- The Authenticode signature of a PE file follows the PKCS#7
putation? Is there any other issues affecting it? Are there any structure that includes the signature (the hash value of the PE
ways to overcome these problems? These questions have mo- file), a timestamp (optional) and the certificate chain. Roughly
tivated our research. Our main research goal in this paper is speaking, the Authenticode signature is a binary data blob con-
to explore whether code signing brings any benefit to memory sisting of a certificate and a signed hash of the file (which
forensics. excludes certain parts of the PE header in the hash calcula-
tion). As hash algorithms, Authenticode supports MD5 (cur-
Contributions. In this paper, we describe the limitations that rently supported only for backwards-compatibility), SHA-1,
memory forensics imposes to the digital signature verification and SHA-256 hashes. Let us note that a PE file can be dual-
process of Windows PE signed files. In particular, Authenti- signed by applying multiple signatures, which is strongly rec-
code is the code signing standard designed to digitally sign files ommended when using deprecated hashing algorithms such as
in Windows, introduced in Windows 2000 (Microsoft Corpora- MD5. The certificate chain is built to a trusted root certificate
tion, 2008). We focused on Windows since it is still the pre- by using X.509 chain-building rules. This trusted root certifi-
ferred target of malware authors (AV-TEST, 2019). We have cate is mandatory as long as the root certificate is not present in
also developed a Volatility plugin to verify digital signatures the users’ root stores.
in a memory dump, named sigcheck (as the tool provided by An Authenticode-signed Windows file can be shipped in two
Microsoft for verifying digital signatures on binary files (Russi- different ways, either through an embedded signature within
novich, 2019)). When feasible, our plugin works on kernel- the PE file structure or through a digitally-signed catalog file.
space file objects that represent executable files, computing the Whether embedded signed or catalog signed, both signatures
signature and verifying the certificate chain attached to the digi- are stored as PKCS #7 signed data, which follows the Abstract
tal signature. To assess the reliability of our plugin, we tested it Syntax Notation One (ASN.1) format (ITU-T, 1984).
in different scenarios and in signed malware samples. We con- ASN.1 is a joint standard of the International Telecommu-
cluded that the longer a system runs, the fewer file objects can nication Union Telecommunication Standardization Sector and
be acquired. Hence, given the current limitations (data incom- ISO/IEC broadly used in telecommunications, computer net-
pleteness, data changes caused by relocation, catalog-signed working, and cryptography (for instance, ASN.1 is used in
files, and executable file and process inconsistencies), the ver- X.509 certificates). It states how to store binary data of dif-
ification of digitally-signed files does not bring any benefit to ferent data structures and includes a set of encoding rules that
memory forensics. specify how to represent a data structure as a series of bytes to
Structure of the paper. The structure of this paper is as follows. facilitate their serialization. In particular, Authenticode signa-
Section 2 gives background on previous concepts. In Section 3, tures follows the DER-encoded ASN.1 format.
we describe in detail the plugin sigcheck that we have devel- The digital signature data in an embedded Authenticode-
oped. Section 4 details the experimentation and discussion of signed Windows PE file is appended to the file. The offset and
results. Section 5 is devoted to explaining the limitations im- size of the embedded signature is stored in the Security di-
posed by memory forensics and possible solutions. Section 6 rectory entry within the Data directories array of the PE
presents related work. Finally, Section 7 concludes the paper optional header. The Data directories array contains off-
and states plans for future work. sets and sizes of different structures within the PE file, such as
the export, import, or relocation directories, among others. All
1 In this paper, we refer as executable file to the representation of a file as in directories but the security directory store their offsets as rela-
disk and as image file to the representation of a file as in memory. tive virtual address (RVA) offsets, which means that they are the
2
virtual addresses from the PE file once it is loaded into memory. 2. Then, the function CryptSIPRetrieveSubjectGuid (in
On the contrary, the security directory stores its offset as a file CRYPT32) is invoked to retrieve the globally unique iden-
offset. tifier (GUID) –a 128-bit integer number used to identify
The binary data stored at the security directory file offset is a resources– of the SIP implementation. This GUID is
WIN_CERTIFICATE structure (Microsoft Corporation, c), which passed to the function CryptSIPLoad, which loads the
defines the signature length (in bytes), the certificate revision, DLL that implements the specified SIP and sets point-
the type of certificate, and the certificate list. In the case of ers to SIP-related functions appropriately. The Windows’
Authenticode signatures, the certificate type matches a PKCS#7 Authenticode trust provider of PE files is implemented in
SignedData structure. WINTRUST.
A catalog file (extension .cat) collects digital signatures for 3. The first of these called functions is CryptSIPGet-
an arbitrary number of files. It contains a collection of cryp- SignedDataMsg, which retrieves the Authenticode sig-
tographic hashes, each one corresponding to a file that is in- nature from a file. Internally, this function eventually
cluded in the collection. To prevent unauthorized modifications, invokes to the function ImageGetCertificateData (in
catalog files are also Authenticode-signed files. Catalog files imagehlp DLL) to retrieve the Authenticode signature
are located in the system32/catroot path within the Win- from the given file.
dows directory (normally, C:\Windows). The database of cat- 4. Once the signature is retrieved from the file, the function
alog files in a Windows system is maintained in a separate file, CryptSIPVerifyIndirectData is invoked to verify the
named catdb, which is located in the system32/catroot2 hash of the file. When computing the Authenticode hash
path within the Windows directory. This database follows the of a PE file, certain parts of the PE file are skipped: the
Extensible Storage Engine (ESE) format, an indexed and se- Authenticode signature itself, the pointer reference to the
quential access method storage technology developed by Mi- location of the Authenticode signature (located in an entry
crosoft. of the data directories), and the PE file checksum (located
in the optional header). This functions returns a boolean
Signature Verification of Authenticode-Signed Windows Files value indicating whether the Authenticode hash verifica-
Microsoft designed the subject interface package (SIP) archi- tion was succeeded.
tecture to support the creation, retrieval, and hash calculation 5. Once the Authenticode hash is validated, the pro-
and validation of digital signatures, abstracting software devel- cess continues invoking the function CryptVerifyTime-
opers about any inner behavior. The verification of signed code StampSignature to validate the timestamp signature on
is performed using a trust provider, which is a piece of software the Authenticode data though a Time Stamping Authority,
that decides whether a given file is trusted based on the certifi- which certifies that it observed the signed data at a specific
cate associated to that file. Every trust provider establishes its time. This step is optional since a signature may optionally
own criteria to validate a signed file. A more detailed expla- be timestamped.
nation of SIP and trust providers architectures, as well as their 6. When the certificate chain needs also to be validated, the
intrinsic relationships, is given in (Graeber, 2018). In a nut- verification process continues after the validation of the
shell, a series of Windows APIs of distinct system’s dynamic Authenticode signature. The function CertGetCertifi-
link libraries (DLLs) are invoked to verify the digital signature cateChain (in CRYPT32) is eventually invoked, which
of a file. builds a certificate chain context starting from an end
We have manually checked the execution flow followed by certificate and going back (if possible) to a trusted root
the Windows OS to verify an Authenticode-signed file. To do certificate. This function accepts some flags to indicate
so, we have extracted and then analyzed the Windows API trace whether extra processing is required. In our experiments,
of an execution of the Sysinternals’ sigcheck (Russinovich, we have observed that the Sysinternals’ sigcheck
2019) tool when verifying an embedded-signed file. The main tool uses the value CERT_CHAIN_CACHE_END_CERT |
core steps of the verification process is done by the WINTRUST CERT_CHAIN_REVOCATION_ACCUMULATIVE_TIMEOUT
and CRYPT32 DLLs. The (summarized) execution flow is as | CERT_CHAIN_REVOCATION_CHECK_CHAIN_EX-
follows: CLUDE_ROOT. A full description of these flags is given
in (Microsoft Corporation, a).
1. First, the function WinVerifyTrust (in WINTRUST) is
invoked (Microsoft Corporation, d). This function per- The verification process of a catalog-signed file is done in
forms a trust verification action on a specified object, in- a programmatic way. The functions needed are defined also
quiring to a trust provider that supports the action iden- in WINTRUST and have CryptCAT as prefix in the function
tifier passed by parameter. We are interested in the Au- name. A correct way to implement this is to first acquire a han-
thenticode trust provider, specified by the WINTRUST_- dle to a catalog administrator context (function CryptCATAd-
ACTION_GENERIC_VERIFY_V2 action identifier. Fur- minAcquireContext –it requires to later invoke the function
thermore, this function accepts a structure named WIN- CryptCATAdminReleaseContext), then to compute the Au-
TRUST_DATA where we can explicitly indicate if we want thenticode hash of the file using the function CryptCATAdmin-
to perform the certificate revocation process, among other CalcHashFromFileHandle, and finally get the handle to the
verification options. catalog that contains the given hash using the function Crypt-
3
CATAdminEnumCatalogFromHash. Once the specific catalog 3. Description of the plugin sigcheck
is retrieved, the function WinVerifyTrust can be invoked to
verify the file signature against that given catalog. Internally, This section describes the Volatility plugin that we devel-
since the catalog file is also an Authenticode-signed file, the oped to verify digital signatures of executable files (namely,
function WinVerifyTrust may perform as indicated before to .exe, .dll, and .sys files) in memory dumps. We named
validate the signature of the catalog file. the plugin sigcheck, as the Microsoft’s tool that verifies digi-
tal signatures on binary files (Russinovich, 2019). We have se-
lected Volatility as memory forensics framework since it has be-
2.2. File Objects come a de facto standard for analyzing memory dumps in com-
puter forensics. Initially released in 2007 (Walters and Petroni,
File Objects represent the memory mapped files into the ker- 2007), Volatility is currently an open source project that sup-
nel memory, acting as the logical interface between kernel and ports the analysis of memory dumps from the main-streams op-
user-mode processes and the corresponding file data stored in erating systems (namely, Windows, Linux, and macOS), and
the physical disk (Microsoft Corporation, b). This object is in both 32-bit and 64-bit architectures. Every supported OS
used by Windows to track a single open instance of a file (that has its own profile, which helps Volatility to find the references
is, if you open multiple times a file, you have multiple file ob- to internal OS structures within the memory dump. Volatility
jects) (Russinovich et al., 2012). The representation of this in- is implemented in Python and incorporates an API that allows
ternal memory structure is depicted in Figure 1. Apart from the developers to implement their own plugins or to extend the fea-
data written to the file, the file object contains a set of kernel- tures of the official tools very easily.
maintained attributes, such as a pointer to the Unicode-encoded Our plugin relies also on a set of plugins shipped with Volatil-
file name and a pointer to a structure named Device object ity. In particular, it uses tasks (to retrieve the list of processes
that represents the device which contains the file. in execution), modules (to retrieve the list of drivers), device-
A file object also stores a pointer to a SECTION_OBJECT_- tree (to retrieve the driver objects for a given module), file-
POINTERS structure, used by the memory manager and cache scan (to retrieve the list of file objects), and dumpfiles (to
manager to store file-mapping and cache-related information obtain the list of memory addresses associated to a FileOb-
for a file stream. This structure is conformed by three opaque ject structure. The content of these addresses is later read in a
pointers (DataSectionObject, SharedCacheMap, and Im- programmatic way).
ageSectionObject). An opaque pointer points to a data struc- Algorithm 1 shows a pseudo-algorithm of the workflow fol-
ture whose contents are not exposed at the time of its definition. lowed by sigcheck to verify the digital signature of an exe-
The pointer DataSectionObject is used to track state in- cutable module e, contained in a memory dump M, both given
formation for a data file stream. That is, it may pointer to data as inputs. As output, it returns a status code to indicate whether
files such as those used by a word processor o a spreadsheet. or not the digital signature of e was verified. This status code is
Similarly, the pointer ImageSectionObject is used to track then parsed to a user-friendly message to report the user appro-
state information for an executable file stream. Roughly speak- priately.
ing, it points to executable files mapped into memory (images). As first step, the plugin obtains the file object f associated to
The pointer SharedCacheMap points to a structure used by the the executable module e (line 1). Then the boolean flag pe_re-
Windows OS to maintain the cache. built is initialized to false value (line 2). If f does not exist or
Only DataSectionObject and ImageSectionObject are does not contain any valid data, it returns FILEOBJECT_ER-
of interest to our research, since both structures are useful to ROR (lines 2–3). In our experiments, every file object that we
look for executable files. In a memory dump, we can look found contained either a DataSectionObject or an Image-
for the file objects handled by the Windows OS at the time the SectionObject valid pointer (cf. Section 2.2). These memory
memory dump was acquired. We may find a DataSectionOb- zones are then checked for completeness.
ject pointing to the memory zone where the executable file When data is complete (lines 5–43), first the end padding
was mapped as data file –although it may contain end padding is removed from the file object f . Then, f is interpreted as
bytes by memory alignment issues. Similarly, we may also a PE file and stored in p (line 7). If f is in fact an Image-
find an ImageSectionObject pointing to the memory zone SectionObject structure, then we look for an image address
where the executable file was mapped prior to be initialized by a ∈ A such that the computation of the PE checksum is correct
the Windows PE loader – that is, a memory zone that contains after undoing any relocation, considering that value as image
the image file after the relocation process was done to prepare address (line 9). Note that our tool needs a list A of frequent
the image for execution. As before, it may contain also end image base addresses. We have populated this list after ana-
padding bytes. Unlike DataSectionObject, an ImageSec- lyzing all system executable files in the Windows OS flavors
tionObject is missing the data related to the Authenticode used in the experiments (cf. Section 4). In case that no valid
signature contained in the PE header. We argue that the PE address is found, it returns PE_REBUILT_FAILED (lines 10–
loader strips this data before mapping the file, since it is used to 11). Otherwise, the flag pe_rebuilt is set to true value. Then,
verify the file prior execution and thus it is not longer needed. the validation of the PE checksum is performed only if pe_re-
Surprisingly, though, this internal structure contains the reloca- built is false, and if there is a mismatch, it returns PE_CHECK-
tion information even it is neither longer needed. SUM_MISMATCH (line 17). Otherwise, the verification of the
4
 Input: A memory dump M and an executable module e
Output: Returns a status code indicating whether the verification of digital signature was successful or failed otherwise
/* Let A be the list of frequent image base addresses */
1 Extract from M the file object f associated to e
2 Initialize the flag pe_rebuilt to false value
3 if f does not exists or does not contain data then
4 return FILEOBJECT_ERROR
5 else if data content of f is complete then
6 Delete end padding of f (if any)
7 Let p be the content of f , interpreted as a PE file
8 if data content of f is an ImageSectionObject then
9 Select an image address a ∈ A such that the PE checksum of p is correct, after undoing the relocation process
10 if a is not found then
11 return PE_REBUILT_FAILED
12 else
13 Set the flag pe_rebuilt to true value
14 end
15 end
16 if not pe_rebuilt and PE checksum of p is incorrect then
17 return PE_CHECKSUM_MISMATCH
18 else
/* cf. Algorithm 2 */
19 return validate_signed_PE_file(p, pe_rebuilt)
20 end
21 else
22 Let p be the content of f , interpreted as a PE file
23 if p cannot be read as a PE file then
24 return PARTIAL_CONTENT_PE_DATA_ERROR
25 end
26 if p contains an embedded Authenticode signature then
27 if data content of f is an ImageSectionObject then
28 return SIGNED_FILE_NOT_VERIFIED
29 else
30 if the certificate chain c, contained in p header, exists then
31 return Verification of the certificate chain c, prefixing it with PARTIAL_CONTENT
32 else
33 return CONTENT_SIGNED_NOT_VERIFIED
34 end
35 end
36 else
37 if f is located in Windows system root directory then
38 return PARTIAL_CONTENT_MAYBE_CATALOG_SIGNED
39 else
40 return PARTIAL_CONTENT_NOT_SIGNED
41 end
42 end
43 end
Algorithm 1: Pseudo-algorithm of the analysis performed by the plugin sigcheck.

5
 FILE_OBJECT structure
... Executable file as con-
DeviceObject SECTION_OBJECT_POINTERS structure tained in disk device
... DataSectionObject (it may contain end padding)
SectionObjectPointer SharedCacheMap
... ImageSectionObject Image file (after relocation
FileName done by the loader). Authenti-
... code signature data is stripped
(it may contain end padding)

Figure 1: Representation of navigation from a FILE_OBJECT structure to DataSectionObject and ImageSectionObject structures.

Input: A PE file p and a boolean value pe_rebuilt

Output: Returns a status code indicating whether the verification of digital signature was successful or failed otherwise
/* Let H be the list of hash values contained in every catalog file */
1 Compute h p as the Authenticode hash of p
2 if the certificate chain c, contained in p header, exists then
3 Retrieve the Authenticode hash value from c as hc
4 if h p is equal to hc then
5 return Verification of the certificate chain c
6 else
7 if pe_rebuilt then
8 return AUTHENTICODE_SIGNATURE_MISMATCH_OR_INCORRECT_IMAGEBASE
9 else
10 return AUTHENTICODE_SIGNATURE_MISMATCH
11 end
12 end
13 else
14 if hA ∈ H then
15 return CATALOG_SIGNED
16 else
17 if f is located in Windows system root directory then
18 return MAYBE_CATALOG_SIGNED
19 else
20 if pe_rebuilt then
21 return NOT_SIGNED_OR_INCORRECT_IMAGEBASE
22 else
23 return NOT_SIGNED
24 end
25 end
26 end
27 end
Algorithm 2: Pseudo-algorithm of the signature verification process.

PE signed file p is validated through the steps shown in Algo- If the Authenticode header is missing, it is checked whether
rithm 2 (explained below). When data is incomplete (lines 21– the file object f is located in the Windows directory or its sub-
39), first f is interpreted as a PE file and stored in p (line 22). directories (line 34). In that case, the tool returns PARTIAL_-
If there is some error with the PE data content (e.g., important CONTENT_MAYBE_CATALOG_SIGNED or PARTIAL_CON-
data is missing), it returns PARTIAL_CONTENT_PE_DATA_- TENT_NOT_SIGNED otherwise (lines 38 and 40, respectively).
ERROR. Then, it is checked if p contains an embedded Authen- The verification of an Authenticode-signed file has been im-
ticode signature. If so, if the data content of f is an ImageSec- plemented as an independent Python function (named sigval-
tionObject structure, the tool returns SIGNED_FILE_NOT_- idator), and thus it can be used with image files as well as with
VERIFIED (line 28). Otherwise, if the certificate chain c ex- executable files. Its workflow is detailed in Algorithm 2. As in-
ists, it is verified (line 30). We rely on OpenSSL 1.1.0l binary put, it needs a PE file p and a boolean value to indicate whether
package for this purpose, following a strict certificate validity the PE file was rebuilt.
time. Unfortunately, we have empirically tested that this soft-
First, the Authenticode hash h p of p is computed (line 1). The
ware does not verify the revocation of certificates. We plan to
steps of the Auhtenticode algorithm are published in (Microsoft
solve this issue programmatically as future work. Our plugin
Corporation, 2008). If p contains an Authenticode header, it
returns the result of the certificate chain verification (explained
is retrieved to extract its Authenticode signature hc and the
below), prefixing it with PARTIAL_CONTENT. If c does not
certificate chain c. When the Authenticode hashes hc and h p
exists, the tool returns CONTENT_SIGNED_NOT_VERIFIED.
mismatch (line 4), it returns either AUTHENTICODE_SIGNA-
6
TURE_MISMATCH or AUTHENTICODE_SIGNATURE_MIS- top of VMware Workstation 15 Pro 15.0.2 build-10952284. Al-
MATCH_OR_INCORRECT_IMAGEBASE, depending on the though we initially also considered Windows 8.1 and Windows
flag pe_rebuilt. Note that by probability of collisions, it may 10, we discarded them from the experimentation since one of
happen that an image address value was selected such that the the Volatility plugins on which sigcheck relies (in particular,
PE checksum is correct when rebuilding the PE file, but how- dumpfiles) was not working appropriately. We plan to inves-
ever, it was not the original image address value (in line 9 of tigate this particular problem further.
Algorithm 1). Hence, the Authenticode hash computed would Apart from a freshly installed OS, we have installed ad-
be surely different from the real one. When both Authenticode ditional software commonly used by users on both virtual
hashes match, the certificate chain c is verified (line 5) with machines, such as Mozilla Firefox 69.0.3, Google Chrome
the OpenSSL binary package. If the Authenticode header is 77.0.3865.120, Libre Office 6.3.1, Notepad++ 7.8, and Adobe
missing (i.e., the offset value in the PE header is zero), it is Reader DC 2019.012.20036. Every virtual machine was ex-
checked if h p ∈ H, where H is the list of known hash values ecuted 10 times and to provide an effectiveness measure of
extracted from catalog files (line 14). Let us note that our tool sigcheck over time, the memory of these machines was ac-
needs a list H of known hash values. Our tool directly extracts quired in four different time moments: at a fresh boot and after
these hash values from the catalog files stored in a given di- 10, 20, and 30 minutes of user activity (with data documents
rectory. If the hash is found, it returns CATALOG_SIGNED. opened and viewing YouTube content with Mozilla Firefox).
Otherwise, it is checked if the file object f is located in the The processes captured in each of these dumps correspond to
Windows directory or in any of its subdirectories. In that case, the ones related to the normal Windows OS activity plus the
we assume that the file is cataloged-signed but hA < H, and ones related to the additional software installed.
the tool returns MAYBE_CATALOG_SIGNED (line 18). Other- Figure 2 shows the average of FileObject types retrieved
wise, the tool returns either NOT_SIGNED or NOT_SIGNED_- by sigcheck in 10 memory dumps of Windows 7 SP1 x86 (top
OR_INCORRECT_IMAGEBASE, depending of the value of the figure) and Windows 7 SP1 x64 (bottom figure), obtained at
input flag pe_rebuilt. different time moments. Recall that our plugin allows to verify
Finally, let us describe the possible return values of the cer- the signature of executable files (extension .exe), dynamic-link
tificate chain verification process. After the verification pro- library files (extension .dll), and driver files (extension .sys).
cess done by OpenSSL, our plugin may return the following:
CERT_EXPIRED, when the certificate validity time passed; Discussion. The results show that there are more chances of
CERT_UNTRUSTED, when the certificate comes from an un- retrieving file objects with complete data at fresh boot. As ex-
known publisher; CERT_FORMAT_ERROR, when there is an pected by the way of working of Windows’ memory subsystem
issue with the certificate structure as missing fields or mal- (page smearing, demand paging, and swap pages), the num-
formed certificate; CERT_VERIFICATION_SUCCESS, when ber of file objects with full content quickly drops as the time
the certificate chain verification was successful. As explained evolves. Furthermore, the results in a 32-bit OS are better than
above, currently OpenSSL does not verify the revocation of cer- in 64-bit OS, for all scenarios. In Windows 7 x86, almost half
tificates. We are currently extending our plugin to include also of driver files are successfully verified as catalog-signed files,
this feature, adding CERT_REVOKED into the set of possible while executable and DLL files reach more than 30%. It is re-
return values to report the user if any certificate of the chain is markable that the content of a huge percentage of file objects
revoked. is partial, seeming not signed or with an incorrect image base
To foster research in this area and enable the reproducibil- address. In 64-bit DLL files, this percentage increases remark-
ity of experiments, both the plugin sigcheck and the auxiliary ably. Finally, let us also remark that none of the file objects
tool sigvalidator have been released under GNU/GPL ver- retrieved in both scenarios contained the Authenticode signa-
sion 3 license and are freely available at https://github. ture as full content. Only 13 32-bit DLL files contained the
com/reversea-me/sigcheck. certificate header, but it was incomplete due to memory paging
issues.
4. Experiments and Discussion
4.2. Analysis of Signed Malware Samples
In this section, we detail the experiments performed with
In this part, we selected a number of signed malware sam-
sigcheck. We have considered two different experiments. In
ples (Niemelä, 2010) from public repositories. Table 1 shows
the first experiment, we measure the effectiveness of sigcheck
the SHA-256 of the selected samples for experimentation.
analyzing a set of memory dumps from different machines. In
When preparing this paper, we found a recent malware threat
particular, we compute how many file objects are retrieved from
that was distributed also as a signed file (malware04). We also
memory dumps under different scenarios. The second experi-
extract the most likely family names from VirusTotal reports to
ment is focused on the analysis of signed malware samples.
label every malware sample using the AVClass malware label-
ing tool (Sebastián et al., 2016).
4.1. Effectiveness of sigcheck We have analyzed every malware sample with sigcheck
For experiments, we have considered a Windows 7 SP1 OS through the auxiliary tool sigvalidator (cf. Section 3, Al-
Enterprise edition Build 7601 in both 32 and 64 bits, running on gorithm 2). Table 2 collects the experiment results. For every
7
 35 Partial file content. Not signed file
Partial file content. Signed file, but not verified 120 Partial file content. Not signed file
Partial file content. Signed file, but not verified
Unable to reconstruct PE file Partial file content. Unable to load PE
Verification successful (catalog-signed) Unable to read FileObject
30 2500 Unable to reconstruct PE file
100 Verification successful (catalog-signed)

25
Number of File Objects

2000

Number of File Objects

Number of File Objects
Embedded certificate incomplete
80
20 Not signed file
Partial file content. Not signed file
1500 Partial file content. Signed file, but not verified
Partial file content. Unable to load PE 60
15 Unable to read FileObject
Unable to read PEB
Unable to reconstruct PE file
1000 Verification successful (catalog-signed)
40
10

5 500 20

0 0 0
Fresh boot 10 min 20 min 30 min Fresh boot 10 min 20 min 30 min Fresh boot 10 min 20 min 30 min
Snapshot time Snapshot time Snapshot time

(a) Win7 x86 EXE files (b) Win7 x86 DLL files (c) Win7 x86 SYS files
Not signed file
35 3000 Partial file content. Not signed file
Partial file content. Signed file, but not verified
Partial file content. Unable to compare file hash and signature hash
40 Partial file content. Unable to load PE
30 2500
Unable to read FileObject
Unable to reconstruct PE file
Verification successful (catalog-signed)
Number of File Objects

Number of File Objects

25 30
Number of File Objects

Not signed file 2000 Embedded certificate incomplete

Partial file content. Not signed file Not signed file
20 Partial file content. Signed file, but not verified
Partial file content. Unable to load PE
Partial file content. Not signed file
Partial file content. Signed file, but not verified
Unable to load PE 1500 Partial file content. Unable to load PE

15
Unable to read FileObject
Unable to reconstruct PE file
Unable to load PE
Unable to read FileObject
20
Verification successful (catalog-signed) Unable to reconstruct PE file
Verification successful (catalog-signed)
1000
10
10
5 500

0 0 0
Fresh boot 10 min 20 min 30 min Fresh boot 10 min 20 min 30 min Fresh boot 10 min 20 min 30 min
Snapshot time Snapshot time Snapshot time

(a) Win7 x64 EXE files (b) Win7 x64 DLL files (c) Win7 x64 SYS files

Figure 2: Average of FileObject types retrieved by sigcheck in 10 memory dumps of Windows 7 SP1 x86 (top figure) and Windows 7 SP1 x64 (bottom figure)
obtained at different time moments.

Label SHA-256 hash AVClass result

malware01 012503199e73d10c3f9f1b3db4876100bf1aebaea53c5da9b8b746a78cf65276 polycrypt
malware02 0da7bf4ee9884242fa2b413ecfd9b7efca2e5ccc9a87a308328c7e8279b24d20 perfectdefender
malware03 178c6f7ad9a2fa6b10e0df89f2d0893afab2215684fffb2ffa4db07f19e95833 trustedzone
malware04 2fc0512083ca44f2669815a8ce8fdcf1eaac63a282fbbc4c1c0892422816251f megacortex
malware05 49dbf0e4f7aebb512fcd081ff5f1dbb2ec5ded98a3fbd5882e2c4c2f1a5c25e4 sobit
malware06 6910f947b942a0484097e0b95d54e49582801a93bf2ab62382f9ef45f8f2b5ac pernefed
malware07 850c4554528c82d12a1a31f308f5b7a9b8d15eb453e65748dd5c65555ab6ba98 perfectdefender
malware08 a8bcc4f6564a96a4602584a06c5e17d0fab2f15a07a49c208657d6a37162ef24 geral
malware09 b057f90eac6a3427e95ffd8bc502659cad08206b0b560f30ab5db9e4b90bb9fd perfectdefender
Table 1: Signed malware samples used in the experiments.

malware sample, we show the problem of the certificate (ex- as the certificate validity time. We believe that apart from the
pired and revoked by issuer; only expired or only revoked by the publisher trustfulness, a certificate expired should always be re-
issuer; and self-signed certificate), the warning window shown ported, as our plugin does. Moreover, the messages shown by
to the user by the Windows UAC in a Windows 10 x64 Stable the Windows UAC are less intuitive for the users. The case
1809 OS when executing the sample (from more trust to less of self-signed certificate (malware08) is detected by the three
trust: asking for permission to make changes, verified publisher tools, although text messages differ slightly. The most interest-
[blue color]; asking for permission to make changes, unknown ing case is malware04, a malware threat associated to the ran-
publisher [yellow color]; and execution blocked [red color]), somware MegaCortex (Brandt, 2019). Although SysInternal’s
and the results of execution of the SysInternal’s sigcheck sigcheck warns that the certificate was revoked by the issuer,
tool (Russinovich, 2019) and our plugin sigcheck. Let us re- surprisingly the Windows UAC tells the user that the file comes
mark that we have selected this version of Windows OS instead from a verified publisher. This difference may be caused by
of Windows 7 (as in experimentation) since we are interested in the parameter settings when calling to WinVerifyTrust. Sim-
the most updated messages of Windows UAC. ilarly, our plugin also returns that the verification process was
successful. Recall that as discussed in Section 3, sigcheck
does not perform any certificate revoking checking, since it is
Discussion. The results indicate that both Windows UAC and
not supported by the OpenSSL binary package on which our
SysInternal’s sigcheck are more focused on the publisher
plugin relies. We are currently implementing the certificate re-
trustfulness rather than other aspects of the certificate, such
8
 Sample Real issue with the certificate Windows UAC SysInternal’s Sigcheck Plugin sigcheck
malware01 Certificate expired and revoked Verified publisher (blue color) Signed Certificate expired
by issuer
malware02 Certificate expired Verified publisher (blue color) Signed Certificate expired
malware03 Certificate expired and revoked Execution blocked (red color) Certificate revoked by issuer Certificate expired
by issuer
malware04 Certificate revoked by issuer Verified publisher (blue color) Certificate revoked by issuer Verification successful
malware05 Certificate expired Verified publisher (blue color) Signed Certificate expired
malware06 Certificate expired Verified publisher (blue color) Signed Certificate expired
malware07 Certificate expired Verified publisher (blue color) Signed Certificate expired
malware08 Self-signed certificate Unknown publisher (yellow color) Root certificate untrusted (un- Issuer certificate missing
der current security policies)
malware09 Certificate expired Verified publisher (blue color) Signed Certificate expired

Table 2: Experiments with signed malware samples.

vocation process using the OpenSSL library to fix this issue. Data changes caused by PE relocation. As discussed in Sec-
tion 2.2, a DataSectionObject is a perfect copy of the exe-
cutable file when we eliminate the end padding added due to
5. Limitations page alignment issues. However, an ImageSectionObject is
created after the Windows PE loader makes the relocation pro-
cess, and thus apart from the end padding there are also bytes
This section reviews the main limitations imposed by mem- that change, such as the image base address (located in the PE
ory forensics to the verification of digitally signed Windows PE header) and every absolute address defined in the relocation
files that we have identified in our study. We also discuss some section or other function tables of the executable file. This issue
possible solutions to these limitations. imposes two major limitations to our approach:

Data incompleteness. Although during our experiments we • In 64-bit files, there are a total of 252 possibilities for an
have always found file objects corresponding to different image address value (considering an offset of 0x1000 be-
mapped files, in most of the cases data were incomplete. tween memory addresses). Therefore, it is computation-
The Windows memory manager swaps physical memory pages ally infeasible to brute-force the image address. To over-
when it needs to use more memory than actually available in come this limitation, our plugin considers the most com-
RAM. Apart from this, page smearing and demand paging are mon image base addresses of every version of Windows
also obstacles to obtain an image file that exactly matches with OS, empirically obtained. This implies that sigcheck
its corresponding executable file. Page smearing refers to the may reconstruct the executable file and consider it as
inconsistency in the page tables and the content of physical wrongly signed if a Windows update changes the image
memory pages due to changes during the acquisition process, address of that file to a value not considered by sigcheck.
while demand paging is an optimization mechanism used by • To verify a successful reconstruction of the executable file,
the OS to load data into memory only when it is absolutely we have opted for using the value of the CheckSum at-
needed (Case and Richard, 2017). Note that the calculation tribute, located at the PE optional header. Although stored
of the Authenticode signature needs the full PE file, excluding in a 32-bit value, it is in fact a 24 bit checksum (the higher
only certain parts (cf. Section 2.1). Hence, if only one memory nibble is discarded) computed using an additive checksum
page of an image file is missed, the signature of that file cannot algorithm which serves as redundancy check. Thus, since
be computed correctly. the number of possible collisions is high (1/224 ), it may
A possible solution to overcome this issue is to guarantee happen that sigcheck finds an image address value such
that the Windows PE loader locks memory pages that contain that the PE checksum is correct, but the computed Auht-
file objects (Russinovich et al., 2012). In this regard, it should enticode hash value is invalid.
always maintain an open reference to every mapped file while
Furthermore, let us recall that the Authenticode signature
the corresponding process is on execution. Of course, this so-
data, which is contained in the security directory of the
lution imposes a performance penalty, since physical memory
PE header, is not mapped into the ImageSectionObject
pages are “wasted” containing data that are unused and thus
structure. Therefore, if the executable file is an embedded
the memory pages could be paged out or even freed. How-
Authenticode-signed file, using this internal structure we can
ever, the memory of current computer systems is in the order
only tell that the file is signed but its signature cannot be ver-
of gigabytes and thus this penalty may be negligible. This is an
ified (since we are unable to retrieve the signature data from
open question that deserves further investigation. Other solu-
memory).
tion might be a combined analysis of a memory dump and their
corresponding swap files (up to 16 paging files of different sizes When the relocation data exist in the ImageSectionObject
in Windows OS (Russinovich et al., 2012)). structure, we can easily revert the relocation process performed
9
by the Windows PE loader. However, since we are unaware of Volatility plugins more focused on malware detection such as
the original image base address of the executable file, it is diffi- malfind or clamav, or more focused on process similarity as
cult to generate a valid Authenticode signature. A solution that ProcessFuzzyHash (Rodríguez et al., 2018).
might overcome this problem is the use of a database storing
the version information, Authenticode hash signature, and im-
age address values for every system file of each Windows OS 6. Related Work
flavor (and associated updates). Of course, the database would
quickly grow up given the vast amount of system files in all There are works regarding the analysis and the presence
Windows OS flavors. of Authenticode-signed files in malware landscape, as well as
highlighting the weaknesses of code signing in Windows.
Catalog-signed files. As shown in Section 4, many system One of the first works showing the abuse of software digital
files in Windows are catalog-signed PE files. To verify every certificates and the presence of malware samples signed with
signature, we need the catalog database that contains that hash rogue certificates was (Wood, 2010). The common pitfalls of
signature. This implies that we need to have every possible cat- certificate authorities that allow the prevalence of signed mal-
alog file for every Windows OS flavor, as well as any of their ware samples are also introduced in this paper. The presence of
updates. For instance, the database of catalogs that we used in signed malware samples was also confirmed by (Kotzias et al.,
our experiments is about 200MB, distributed over 8784 files. 2015), where a malware dataset of 356K samples from 2006 to
However, this database only contains data from the versions of 2015 was analyzed. They concluded that most signed samples
Windows 7 and Windows 10 used in experimentation (cf. Sec- in the dataset were potentially unwanted programs (between
tion 4), as well as a version of Windows 8.1. 88% − 95%), while only a few were signed samples of malware
(5% − 12%).
At the moment of this writing, there is not a central- (Kim et al., 2017) proposed a threat model which highlights
ized database of catalog data. State-sponsored CERTs (or some weaknesses in the use of code-signing technology, af-
university-related CERTs) could lead this initiative and main- ter detecting that signed malware may cause anti-virus (AVs)
tain this database, providing a public web service to check the products to stop analyzing them. The highlighted weaknesses
database for other incident response teams. are related to inadequate client-side protections (such as the
use of AVs that skip analysis of signed binaries), publisher-
Executable file and process inconsistencies. Our plugin re-
side key mismanagement (an inadequate security management
lies on the file object structure to verify the Authenticode sig-
in the publisher side may facilitate the stealing of private keys
nature. However, it may happen that although the mapped file
that corresponds to the publisher’s certificate or the infection of
is legitimate (i.e., the file contained in the device drive was not
developer machines), and CA-side verification failures (verifi-
manipulated), its corresponding process is malicious. For in-
cation process may fail, resulting in certificates issued to shell
stance, malware can inject malicious code in a legitimate pro-
companies or malicious publishers with stolen identities). They
cess or perform a process hollowing (it occurs when a process
also analyzed a total of 325 signed malware samples, having
is created in a suspended state and then its process memory
a 58.2% of samples properly signed (the rest signed with mal-
is replaced with malicious code) to evade detection and anal-
formed certificates) and classifying the certificate abuse as a
ysis. Currently, our plugin does not detect this kind of eva-
compromised certificate or issued to a fraudulent or shell com-
sion techniques. We have empirically tested that these evasion
pany.
techniques are also undetected by other forensic programs that
In a similar work, (Kozák et al., 2018) studied the under-
verify Authenticode signatures from running processes in live
ground market of code signing certificates, identifying 4 lead-
systems, such as Process Explorer and Process Hacker.
ing vendors of Authenticode certificates. Furthermore, they col-
In our opinion, this is one of the biggest challenges in mem- lected 14, 221 signed malware samples and analyzed the certifi-
ory forensics. To be sure that the binary code of an image file cate attributes to graphically map the relationships among mal-
was unmodified, we need to unmap its corresponding process, ware families and certificates.
reverting all the work performed by the Windows PE loader, The malware dataset focused on Windows built in (Ugarte-
and then compare the unmapped image file with the executable Pedrero et al., 2019) showed that close to 18% of the 172, 612
file. At the moment of this writing, we are unaware of any tool collected samples are signed binaries, with very few (only 11
capable of doing this backward process and comparison reli- samples) using revoked certificates. Signed binaries are also
ably. We could also check the virtual address descriptor (VAD) collected and analyzed in Rivera et al. (2019), where 39% of
tree of a process, looking for strange changes in the permis- 75, 615 malware samples analyzed are signed – three out of four
sions of every VAD node. VAD is a tree data structure used by samples being correctly validated as Authenticode-signed files.
the Windows OS to store information about process memory All of the aforementioned works focus on executable files
regions (Dolan-Gavitt, 2007). A similar idea is used in (Srivas- instead on binary data extracted from memory dumps, as we
tava and Jones, 2017), where a Volatility plugin is introduced do in this paper. To the best of our knowledge, we are the first
to locate injected code using cross-validation with stack infor- to put a spotlight on the analysis of Authenticode-signed files
mation even when VAD nodes have been modified by the mal- extracted from memory dumps and to highlight the limitations
ware to remain stealthy. Of course, we can also rely on other and possible solutions.
10
7. Conclusions and Future Work Kotzias, P., Matic, S., Rivera, R., Caballero, J., 2015. Certified PUP: Abuse
in Authenticode Code Signing, in: Proceedings of the 22Nd ACM SIGSAC
In this paper, we have investigated whether code signing Conference on Computer and Communications Security, ACM, New York,
brings any benefit to memory forensics. In particular, we have NY, USA. pp. 465–478. doi:10.1145/2810103.2813665.
Kozák, K., Kwon, B.J., Kim, D., Gates, C., Dumitras, T., 2018. Issued for
focused on Windows OS. However, due to how Windows works Abuse: Measuring the Underground Trade in Code Signing Certificate.
and the current limitations of memory forensics (such as pag- CoRR abs/1803.02931.
ing memory, page smearing, and demand paging), the verifi- Langner, R., 2011. Stuxnet: Dissecting a Cyberwarfare Weapon. IEEE Security
cation of digital signatures of processes captured in a memory & Privacy 9, 49–51. doi:10.1109/MSP.2011.67.
Ligh, M.H., Case, A., Levy, J., Walter, A., 2014. The Art of Memory Forensics:
dump is a difficult task. We have highlighted the limitations im- Detecting Malware and Threats in Windows, Linux, and Mac Memory. John
posed by memory forensics (data incompleteness, data changes Wiley & Sons, Inc.
caused by relocation, catalog-signed files, and executable file Microsoft Corporation, a. CertGetCertificateChain- function. [online;
and process inconsistencies), as well as proposed some solu- https://docs.microsoft.com/en-us/windows/win32/api/
wincrypt/nf-wincrypt-certgetcertificatechain]. Accessed
tions. Furthermore, we have developed sigcheck, a Volatility on September 26, 2019.
plugin that verifies a digitally-signed file (if feasible) retrieved Microsoft Corporation, b. FILE_OBJECT structure. [online;
from a memory dump through internal OS structures (in partic- https://docs.microsoft.com/en-us/windows-hardware/
drivers/ddi/content/wdm/ns-wdm-_file_object]. Accessed
ular, file objects). We tested it on Windows 7 x86 and x64. Our on September 30, 2019.
findings indicate that the success rate is low, especially when Microsoft Corporation, c. WIN_CERTIFICATE structure. [online; https:
the memory is acquired from a system that was running for a //docs.microsoft.com/en-us/windows/win32/api/wintrust/
long time. ns-wintrust-win_certificate?redirectedfrom=MSDN]. Accessed
on September 25, 2019.
As future work, we aim to complete the verification process Microsoft Corporation, d. WinVerifyTrust function. [online;
of our plugin with certificate revocation and to further study the https://docs.microsoft.com/en-us/windows/win32/api/
lifetime of file objects. We also aim to explore the solutions wintrust/nf-wintrust-winverifytrust]. Accessed on Septem-
proposed for the current limitations. ber 26, 2019.
Microsoft Corporation, 2008. Windows Authenticode Portable Executable Sig-
nature Format. [online; http://download.microsoft.com/download/
Acknowledgements 9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/authenticode_
pe.docx]. Accessed on September 25, 2019.
Niemelä, J., 2010. It’s Signed, Therefore It’s Clean, Right?, in: CARO 2010
This work was supported in part by the Spanish Ministry of
Technical Workshop.
Science, Innovation and Universities under grant MEDRESE- Pagani, F., Fedorov, O., Balzarotti, D., 2019. Introducing the Temporal Di-
RTI2018-098543-B-I00 and by the University, Industry and In- mension to Memory Forensics. ACM Trans. Priv. Secur. 22, 9:1–9:21.
novation Department of the Aragonese Government under Pro- doi:10.1145/3310355.
Parno, B., McCune, J.M., Perrig, A., 2010. Bootstrapping Trust in Commodity
grama de Proyectos Estratégicos de Grupos de Investigación Computers, in: 2010 IEEE Symposium on Security and Privacy, pp. 414–
(DisCo research group, ref. T21-17R). 429. doi:10.1109/SP.2010.32.
PaX Team, . PaX address space layout randomization (ASLR).
https://pax.grsecurity.net/docs/aslr.txt.
References Rivera, R., Kotzias, P., Sudhodanan, A., Caballero, J., 2019. Costly freeware: a
systematic analysis of abuse in download portals. IET Information Security
AV-TEST, 2019. Malware statistics. [Online; https://www.av-test.org/ 13, 27–35. doi:10.1049/iet-ifs.2017.0585.
en/statistics/malware/]. Rodríguez, R.J., Martín-Pérez, M., Abadía, I., 2018. A Tool to Com-
Bhatkar, E., Duvarney, D.C., Sekar, R., 2003. Address Obfuscation: An Ef- pute Approximation Matching between Windows Processes, in: Proceed-
ficient Approach to Combat a Broad Range of Memory Error Exploits, in: ings of the 2018 6th International Symposium on Digital Forensic and
Proceedings of the 12th USENIX Security Symposium, pp. 105–120. Security (ISDFS), pp. 313–318. URL: http://webdiis.unizar.es/
Brandt, A., 2019. “MegaCortex” ransomware wants to be The ~ricardo/files/papers/RMA-ISDFS-18.pdf, doi:10.1109/ISDFS.
One. [online; https://news.sophos.com/en-us/2019/05/03/ 2018.8355372.
megacortex-ransomware-wants-to-be-the-one/]. Accessed on Russinovich, M., 2019. Sigcheck v2.73. [online; https://docs.
September 30, 2019. microsoft.com/en-us/sysinternals/downloads/sigcheck]. Ac-
Case, A., Richard, G.G., 2017. Memory forensics: The path forward. Digi- cessed on September 25, 2019.
tal Investigation 20, 23–33. doi:10.1016/j.diin.2016.12.004. special Russinovich, M.E., Solomon, D.A., Ionescu, A., 2012. Windows Internals, Part
Issue on Volatile Memory Analysis. 1: Covering Windows Server 2008 R2 and Windows 7. 6th ed., Microsoft
Dolan-Gavitt, B., 2007. The VAD tree: A process-eye view of physical mem- Press, Redmond, WA, USA.
ory. Digital Investigation 4, 62–64. doi:https://doi.org/10.1016/j. Sebastián, M., Rivera, R., Kotzias, P., Caballero, J., 2016. AVclass: A Tool for
diin.2007.06.008. Massive Malware Labeling, in: Monrose, F., Dacier, M., Blanc, G., Garcia-
Graeber, M., 2018. Subverting Trust in Windows. Technical Report. Specter Alfaro, J. (Eds.), Research in Attacks, Intrusions, and Defenses, Springer
Ops, Inc. International Publishing, Cham. pp. 230–253.
ITU-T, 1984. Introduction to ASN.1. [online; https://www.itu.int/en/ Srivastava, A., Jones, J.H., 2017. Detecting Code Injection by Cross-Validating
ITU-T/asn1/Pages/introduction.aspx]. Accesed on September 25, Stack and VAD Information in Windows Physical Memory, in: 2017 IEEE
2019. Conference on Open Systems (ICOS), pp. 83–89.
Kaliski, B., 1998. PKCS #7: Cryptographic Message Syntax Version 1.5. Ugarte-Pedrero, X., Graziano, M., Balzarotti, D., 2019. A Close Look at a
[online; https://tools.ietf.org/html/rfc2315] ed. IETF Network Daily Dataset of Malware Samples. ACM Trans. Priv. Secur. 22, 6:1–6:30.
Working Group. Accessed on September 25, 2019. doi:10.1145/3291061.
Kim, D., Kwon, B.J., Dumitraş, T., 2017. Certified Malware: Measuring Walters, A., Petroni, N., 2007. Volatools: Integrating Volatile Memory Foren-
Breaches of Trust in the Windows Code-Signing PKI, in: Proceedings of the sics into the Digital Investigation Process, in: BlackHat DC.
2017 ACM SIGSAC Conference on Computer and Communications Secu- Wood, M., 2010. Want My Autograph? The Use and Abuse of Digital Signa-
rity, ACM, New York, NY, USA. pp. 1435–1448. doi:10.1145/3133956. tures by Malware. Technical Report. Virus Bulletin Conference.
3133958.

11