Thomas Barabosch

Hello, world, again

Tue, 14 Jul 2026 22:00:00 +0000

Every now and then, a system deserves a clean boot.

I have relaunched this blog with a new design: less ornamental, more direct, and closer to the kind of interface I keep coming back to anyway. Think manpage energy, but for notes on systems security, reverse engineering, malware analysis, threat research, and the occasional opinion that needed more room than a short post elsewhere.

The old posts are still here. New ones should follow.

If you want the updated map of who I am, what I work on, and what belongs on this site, start with the updated about page.

Detect API hashing with YARA

Tue, 16 Mar 2021 16:42:31 +0000

Malware utilizes obfuscation to complicate its analysis. There is one obfuscation technique that targets specifically static analysis: API hashing. In a nutshell, malware uses hashes of API names (e.g. 0x0688eae1) instead of plain strings (e.g. kernel32!Sleep) to obfuscate the API functionality it relies on. This is typically a pretty nasty obfuscation technique since it requires malware analysts to resolve this API hashing before they can conduct a meaningful analysis. There are many advanced malware families that utilize API hashing including Buer, PoisonIvy, PlugX and UrlZone.

As a first step in the triage phase, it is nice to have a first pointer whether or not a malware family could use API hashing and if so which algorithm it uses to hash API names. Therefore, I wrote a tiny project called apihash_to_yara.py that generates YARA rules to detect this behavior fast and without too many false positives. The source code is on GitHub where you’ll also find two sets of precompiled YARA rules.

API hashing is an obfuscation technique that you’ll typically encounter in advanced malware. Normally, the names of APIs are stored in plain text in a binary (e.g. as part of the Import Table of the PE header). Remember that strings and APIs are very important corner stones in the reverse engineering puzzle. Hence, malware authors try to obfuscate them so that malware analysts have to significantly invest more time.

In API hashing, API names are not stored in plain text but rather their hashes are stored in the binary. Malware utilizes these hashes and resolves the addresses to APIs itself. To resolve an API hash h to an API name, it typically hashes the exported APIs of DLL loaded into the process space with an embedded hashing algorithm. Then, it compares each computed hash to h. A good write-up on how malware achieves this by enumerating DLLs via the PEB can be found here.

A common algorithm that you’ll encounter is CRC32. The following Python snippet shows how we can compute the CRC32 hash of the API name Sleep:

>>> import zlib
>>> h = zlib.crc32(b'Sleep')
>>> hex(h)
 '0xcef2eda8'         

Note that we do not have to come up with our own implementations for the many API hashing algorithms that exist in malware since there is already an implementation of many in make_sc_hash_db from flare-ida, which we’ll use later.

To detect this behavior fast with YARA, we do not have to know how the resolving works in detail. We won’t match the embedded algorithm either. Instead, we’ll match the API hashes that have to be stored in the malicious binary somewhere.

There are two ways how malware stores these hashes. Both ways correspond to one way how they are resolved. The first way is to resolve the API hashes during the initialization of the malware. Therefore, the malware comprises an array of API hashes and resolves one after another on startup. For instance, this is what the malware PoisonIvy does. The following screenshot shows the API hash array found in its binary. I’ve marked the hash 0xBA36C10A, which corresponds to the API function Kernel32!Sleep.

The second way is to resolve the API hashes just in time. This means that every time the malware calls an API function, it first resolves the hash. The following screenshot of the malware family VMZeus depicts this behavior. The function resolve_api_hashing takes among other parameters an API hash as input. It resolves the API hash and returns the address to the API in the register eax. This is subsequently called (call eax).

The main idea is to generate one YARA rule for several API hashes that are generated with API hashing algorithm. I didn’t want to reinvent the wheel and therefore I adjusted the API hashing algorithms found in make_sc_hash_db from flare-ida. This project comprises more than a dozen API hashing algorithms.

apihash_to_yara requires a list of DLL names and API names (e.g. kernel32!Sleep) as input and generates based on them a YARA rule set. I recommend to include A / W versions of an API (e.g. SleepA and SleepW) since their API hashes are likely different. If you create your own list using the script generate_api_list.py then this script will handle this for you. Since some malware families store their hashes in little endian format and some in big endian format, both formats are always generated.

There are already two API lists included in the data directory of the project. The first top100_winapi_malpedia.txt comprises the Top100 Windows API functions found in samples hosted on Malpedia. The second API list custom_apis.txt comprises all API names found in common Windows DLLs such as kernel32.dll.

There are two parameters that help you to tweak the detection performance. First, there is the parameter --yara_condition_match_threshold that defines how many API hashes have to be matched in a binary. The default value is 10 API hashes, which is just an educated guess. The value 5 API hashes yielded too many false positives. The second parameter that you could tweak is --yara_condition_filesize_threshold that ensures that only binaries with less than n kilobytes are considered. This is another way to reduce false positives. Feel free to adjust these parameters to your needs. In the following, I’ll list all command line options of apihash_to_yara.py for your reference:

usage: apihash_to_yara.py [-h] [--yara_condition_match_threshold YARA_CONDITION_MATCH_THRESHOLD] [--yara_condition_filesize_threshold YARA_CONDITION_FILESIZE_THRESHOLD] path_api_names output
 positional arguments:
   path_api_names        Path to list of API names
   output                Path to output
 optional arguments:
   -h, --help            show this help message and exit
   --yara_condition_match_threshold YARA_CONDITION_MATCH_THRESHOLD
                         Threshold of required matches in YARA condition
   --yara_condition_filesize_threshold YARA_CONDITION_FILESIZE_THRESHOLD
                         Filesize threshold of required matches in YARA condition

The output of apihash_to_yara.py looks similar to the following:

rule api_hash_ror7AddHash32 {
     meta:
         author = "Thomas Barabosch"
         reference1 = "https://tbarabosch.github.io/apihash-to-yara/"
         reference2 = "https://github.com/tbarabosch/apihash_to_yara"
         reference3 = "https://github.com/fireeye/flare-ida/tree/master/shellcode_hashes"
         reference4 = "https://malpedia.caad.fkie.fraunhofer.de/stats/api_usage"
         api_count = "300"
         yara_condition_match_threshold = "10"
         yara_condition_filesize_threshold = "1024"
     strings:
         $kernel32_dll_Sleep = { cb 97 65 a0 }
         $kernel32_dll_Sleep_little_endian = { a0 65 97 cb }
         $kernel32_dll_SleepA = { 41 97 2f 0c }
         $kernel32_dll_SleepA_little_endian = { 0c 2f 97 41 }
         $kernel32_dll_SleepW = { 41 97 2f 22 }
         $kernel32_dll_SleepW_little_endian = { 22 2f 97 41 }
         $kernel32_dll_CloseHandle = { ff 0d 66 57 }
         $kernel32_dll_CloseHandle_little_endian = { 57 66 0d ff }
         $kernel32_dll_CloseHandleA = { af fe 1b 0d }
         $kernel32_dll_CloseHandleA_little_endian = { 0d 1b fe af }
         $kernel32_dll_CloseHandleW = { af fe 1b 23 }
         $kernel32_dll_CloseHandleW_little_endian = { 23 1b fe af }
 […]
     condition:
         10 of them and filesize < 1024KB
 }

There are two precompiled sets of YARA rules in the repository. First, top100_apis_malpedia.yar (based on the Malpedia API names) and custom_apis.yar.gz (based on custom_apis.txt, gzipped due to size restrictions).

Does it work? – A very unscientific evaluation

No real scientific evaluation here, just some random case studies. I ran top100_apis_malpedia.yar on Malpedia. I had more than 450 matches but this included different versions of a malware family. From 68 families I had at least one match. Throughout the years I’ve analyzed some of these families and remember them to use API hashing (not exactly the algorithm but the fact that they do). While this is a very weak confirmation that apihash_to_yara.py works, I had a look at a handful samples.

I’ll refrain from posting the list of matches due to the TLP:AMBER nature of some of the families. If you’ve access to the Malpedia corpus, please run it yourself. Play a bit with the threshold parameters to avoid false positives. Let me know your results and suggest improvements! Some examples that I stumbled upon are:

Buer (ror13AddHash32Sub20h)
Panda Banker (crc32)
Poison Ivy and PlugX (PoisonIvyHash)

Furthermore, I scheduled a Retrohunt on VirusTotal’s Goodware corpus. Actually, I scheduled two Retrohunts since the maximal size is 1MB per rule set. The top100_apis_malpedia.yar has a filesize of 1.3MB. Therefore, I split the rule set accordingly. In total, there were 7 false positives, all of them matched the rule sll1AddHash32. In environments where you can not tolerate false positives, you should turn off this rule.

Let me quickly conclude what we’ve presented in this blog post. This blog post presented apihashing_to_yara.py, a tiny project to generate YARA rules to detect API hashing in malware fast and without too many false positives. The project can be found on GitHub. There are also two precompiled YARA rules already included. Shout out to the giants on whose shoulders I stand: make_sc_hash_db from flare-ida and Malpedia.

As always, there is always room for improvement. One path that could be followed is finding the perfect condition thresholds. Right now the default value is 10 API hash matches and 1024KB filesize, however these values may be too conservative. Quick tests with lower thresholds (e.g. 5 matches) yielded too many FPs. Another path is adding more API hashing algorithms. If time permits, I’ll port new algorithms from make_sc_hash_db from flare-ida.

Learn how to fix PE magic numbers with Malduck

Thu, 28 Jan 2021 07:00:00 +0000

Malware often corrupts the Portable Executable (PE) header to hinder its analysis. By overwriting parts of the PE header, malware evades simple memory dumpers and thwarts proper loading by analysis tools. If we’re lucky then malware only overwrites the magic numbers of the PE header (MZ and PE) and leaves the rest of the header intact. We can fix such corrupted PE headers with ease. All we need is a little bit of knowledge about the PE format and the right tool to manipulate memory dumps.

First, we’ll learn how to identify such corrupted PE headers quickly with a hexeditor. Next, we’ll see how to manipulate memory dumps with Malduck. This section gives you a head start on how to use this great Python module effectively. Finally, we are putting it all together and write a script to fix PE magic numbers of a corrupted PE header.

In the following, I assume that you’ve got a basic understanding of the PE format. If not, I can recommend the article on osdev.org (check the overview graphic of the PE format) as an introduction.

There are two magic numbers in the PE header that are frequently overwritten by malware. First, the magic number of the DOS header (_IMAGE_DOS_HEADER), which is a two-byte or WORD constant (MZ). Second, the magic number of the PE header, which is a four-byte or DWORD constant (PE\x00\x00). This is illustrated in the following screenshot of a PE file opened in a hexeditor. Both magic numbers are colored in orange. The MZ magic is at offset 0x0 and the PE\x00\x00 is at offset 0x80.

Now that we’ve seen a perfectly fine PE header, let’s see how a slightly corrupted PE header looks like. The next screenshot shows a PE header with both (principal) magic numbers overwritten.

We can still identify that this is likely a PE file since the famous string This program cannot be run in DOS mode is still there. But we are missing these two magic numbers, which in turn hinders many analysis tools to properly load and analyze such a binary.

So, fixing this kind of corrupted PE header is straightforward. First, we have to restore the magic number MZ at offset 0x0. Second, we have to determine the offset to the PE header. The DOS header holds this offset in its field e_lfanew (see next code block with DOS header for reference). Therefore, we have to read the value of e_lfanew from the DOS header. e_lfanew resides at offset 0x3c. Third, we have to restore the PE header magic number PE\x00\x00 at the offset pointed to by e_lfanew. Finally, we should validate, if the file is now a valid PE file.

typedef struct _IMAGE_DOS_HEADER {                
    WORD  e_magic;      /* 00: MZ Header signature */       
    WORD  e_cblp;       /* 02: Bytes on last page of file */       
    WORD  e_cp;         /* 04: Pages in file */       
    WORD  e_crlc;       /* 06: Relocations */       
    WORD  e_cparhdr;    /* 08: Size of header in paragraphs */       
    WORD  e_minalloc;   /* 0a: Minimum extra paragraphs needed */       
    WORD  e_maxalloc;   /* 0c: Maximum extra paragraphs needed */       
    WORD  e_ss;         /* 0e: Initial (relative) SS value */       
    WORD  e_sp;         /* 10: Initial SP value */       
    WORD  e_csum;       /* 12: Checksum */        
    WORD  e_ip;         /* 14: Initial IP value */           
    WORD  e_cs;         /* 16: Initial (relative) CS value */          
    WORD  e_lfarlc;     /* 18: File address of relocation table */       
    WORD  e_ovno;       /* 1a: Overlay number */       
    WORD  e_res[4];     /* 1c: Reserved words */       
    WORD  e_oemid;      /* 24: OEM identifier (for e_oeminfo) */       
    WORD  e_oeminfo;    /* 26: OEM information; e_oemid specific */       
    WORD  e_res2[10];   /* 28: Reserved words */        
    DWORD e_lfanew;     /* 3c: Offset to extended header */       
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

Note that if you encounter a memory dump that starts with around 1000 / 0x400 zero bytes, followed by properly aligned code, then you are likely out of luck. What you are looking at is likely a completely overwritten PE header. Here I’ve encountered two scenarios throughout the years. First, the malware unpacks a perfectly fine PE file and overwrites the PE header, for instance, before injecting it into another process. If this is the case then go back to debugging and dump the PE file before the header is overwritten.

Second, the malware unpacks a PE file with an already corrupted PE header. In this case, you have to restore the PE header. If it is really necessary then you can try to build a PE file from scratch with LIEF. However, this is out of the scope of this blog post.

Manipulating memory dumps with Malduck

Malduck is a Python module that helps writing malware analysis scripts quickly. It is developed and maintained by CERT.pl. Malduck’s documentation is very decent. It is my default go-to tool to write malware analysis scripts (e.g. for aPLib decompression).

Open a memory dump with Malduck

Before we can manipulate memory dumps (of PE files), we have to open them with Malduck. The basis for all memory representations is the class <a class="rank-math-link" href="https://malduck.readthedocs.io/en/latest/procmem.html">Malduck.procmem</a> (alias for malduck.procmem.procmem.ProcessMemory). The constructor takes three parameters:

buf: a buffer of the memory contents (as among others Python bytes)
base (optional): the base address of the memory dump, which defaults to 0x0
regions (optional): a list of regions of the memory dump, defaults to None (not relevant in the following since we’ll work with PE dumps)

We can get the length of a ProcessMemory instance with the method length and close it with close.

Apart from methods for reading and writing (see next sections), there are methods for searching (findmz, findp, findv, regexp, regexv), YARA scanning (yarap, yarav), and disassembling (disasmv). Note that methods may be suffixed with either v (virtual) or p (physical). Methods suffixed with v work on virtual addresses and methods suffixed with p work on physical addresses (raw offsets in the memory dump). The methods p2v and v2p translate from physical addresses to virtual and vice versa.

Based on malduck.procmem.procmem.ProcessMemory, there are four more memory representations in Malduck:

ProcessMemoryPE (alias procmempe) for PE files
ProcessMemoryELF (alias malduck.procmemelf) for ELF files
CuckooProcessMemory (alias malduck.cuckoomem) for memory dumps in Cuckoo 2.x format
IDAProcessMemory (alias malduck.idamem) for working with IDAPython

Since this blog post covers PE files, we will work with ProcessMemoryPE (alias procmempe) in the following. The constructor differs slightly from the constructor of ProcessMemory. The first two parameters are still buf and base. However, it does not take the parameter regions but takes two more parameters:

image (optional): indicate that this is a dump of a memory-mapped PE file, which defaults to False
detect_image (optional): heuristically detects if is a memory-mapped PE file, which defaults to False

A useful method of ProcessMemoryPE is is_valid, which checks if the imagebase of the memory dump points to a valid PE header.

I encourage you to read the documentation to find other hidden gems. There are further methods like extract that tries to extract a malware configuration from the memory dump. See Malduck’s static configuration extractor engine for more information.

Read ProcessMemoryPE

Malduck supports two ways to read from a ProcessMemory instance. First, it allows reading raw data chunks with readp, readv, and readv_until. While readp takes as input a raw offset and an optional length, readv takes as input a virtual addr. The method readv_until is useful when you want to read until a certain stop marker (e.g. end of configuration).

Second, Malduck supports reading various data types:

strings: asciiz and utf16z
signed integers: int8p/int8v, int16p/int16v, int32p/int32v, int64p /int64v
unsigned integers: uint8p/uint8v, uint16p/uint16v, uint32p/uint32v, uint64p /uint64v

Note that there is always a physical (p) and virtual (v) version. Internally, all utilize either readp or readv to read the data.

Write ProcessMemoryPE

The support for writing ProcessMemory instances is rudimentary when compared with the reading support. There are just two functions to know: patchp and patchv. Both accept a raw offset / virtual addr and a bytes buf. That’s it, pretty straightforward!

Putting it all together: fix PE magic numbers with Malduck

This section puts it all together: our theoretical knowledge about the PE format and our practical knowledge about memory dump manipulation with Malduck. The script fix_pe_magic_numbers.py takes a path to a dump of PE file with a corrupted header as input and outputs a fixed dump.

First, it loads the dump into a buffer data and opens it with malduck.procmempe (alias of malduck.procmem.procmempe.ProcessMemoryPE) in line 11. The method is_valid checks if a ProcessMemoryPE object is a valid PE file (line 13). Next, it patches the MZ magic number with the method patchp (line 17) and reads the DOS header field e_lfanew with the method uint32p. Again, e_lfanew resides at offset 0x3C. Afterwards, it patches the PE\x00\x00 magic number with the method patchp (line 24). Finally, it validates the PE file with the method is_valid (line 26). If it is valid, then it writes all bytes of the ProcessMemoryPE object to a file (line 29).

import sys
import malduck

def main(argv):
   `if len(argv) != 2:`
`   print('Usage: fix_pe_magic_numbers.py PATH_TO_DUMP')     `
        `return`

    `with open(argv[1], 'rb') as f:     `
        `data = f.read()`
        `pe = malduck.procmempe(buf=data)     `

        `if pe.is_valid():         `
            `print('This file is already a valid PE file. Skipping...')         `
            `return     `

        `pe.patchp(0, b'MZ')     `
        `lfanew = pe.uint32p(0x3c)     `
        `if lfanew > len(data):         `
            `print('Bogus lfanew value ({hex(lfanew)}). Bailing out...')         `
            `return     `
        
        `print(f'lfanew: {hex(lfanew)}')     `
        `pe.patchp(lfanew, b'PE\x00\x00')     `
        
        `if pe.is_valid():         `
            `print('Fixed file successfully. Dumping to new file...')         `
            `with open(argv[1].replace('bin', '') + '_fixed_header.bin', 'wb') as g:`
 `    `    `g.write(pe.readp(0))         `
                `print('Done.')     `
        `else:         `
            `print('Could not fix file, still not a valid PE file.')     `
        
        `pe.close()`

if <strong>name</strong> == '<strong>main</strong>':
    main(sys.argv)

Let’s see how it works with our broken memory dump from the beginning:

> file memdump.bin
memdump.bin: data
> python fix_pe_magic_numbers.py memdump.bin
 lfanew: 0x80
 Fixed file successfully. Dumping to new file…
 Done.
> file memdump_fixed_header.bin
memdump_fixed_header.bin: PE32+ executable (console) x86-64, for MS Windows

et voilà! The script fixed the memory dump as we can see in the following screenshot:

Both magic numbers are located at their correct offsets: the magic number of the DOS header MZ resides at offset zero and the magic number of the File header resides at offset 0x80 (as indicated by e_lfanew). Now you can load the PE file with other analysis tools and continue your analysis.

The malware analyst's guide to PE timestamps

Fri, 22 Jan 2021 06:00:00 +0000

This blog post is all about time. More exactly, timestamps found in Portable Executable (PE) files that describe a (possible) compilation date. These PE timestamps may even reveal details about a threat actor. For instance, it is possible to deduce a threat actor’s working hours and use this information – hopefully together with other artifacts – for attribution purposes. But be aware: even though PE timestamps can be a valuable forensic artifact, they can be forged with ease. While the COFF header field TimeDateStamp is the most-known place to look for a compilation timestamp, there are more places where we can find timestamps in a PE file.

But there are also special cases where PE timestamps are not correct due to new build features, linker bugs, or simply forging. We’ll look into these cases and see how we can still get some information about the compilation date. Afterward, we’ll learn how to read PE timestamps with a wide range of tools and how to automate this work in order to deal with larger datasets. Of course, there are several real-world applications for malware / cyber threat intelligence analysts of what we’ll learn in this blog post. Finally, I’ll give you some ideas how you can utilize PE timestamps to reveal certain behaviors or characteristics of threat actors.

This article assumes a basic understanding of the PE format. Good beginner write-ups are “An In-Depth Look into the Win32 Portable Executable File Format” and “Portable Executable File Format“. As a follow-up, Ange Albertini wrote a much more detailed technical article on the PE format.

This work wouldn’t have been possible without many great blog posts and papers published by the infosec community. I am standing on the shoulders of giants! I refer to these posts and papers in the following whenever possible.

The probably most cited field of the PE format that holds a compilation timestamp is the field TimeDateStamp of the COFF File Header. It is a DWORD (32 bit / 4 bytes) member of the struct _IMAGE_FILE_HEADER / COFF File Header. This struct is defined as follows:

typedef struct _IMAGE_FILE_HEADER {
  WORD  Machine;
  WORD  NumberOfSections;
  DWORD TimeDateStamp;
  DWORD PointerToSymbolTable;
  DWORD NumberOfSymbols;
  WORD  SizeOfOptionalHeader;
  WORD  Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;

TimeDateStamp is in epoch, which measures the seconds that have passed since January 1, 1970 UTC. Since it is a DWORD value, its range is quite limited. This will lead – if not fixed before – to an integer overflow in the year 2038. Furthermore, epoch should not be confused with Win32 epoch, which starts in the year 1601.

As part of the linking process of the final PE binary, the linker sets the field TimeDateStamp in the COFF File Header. However, its purpose today is mainly supporting the module loader as Raymond Chen lays out in “Why are the module timestamps in Windows 10 so nonsensical?“:

Remember what the timestamp is used for: It’s used by the module loader to determine whether bound imports should be trusted. We’ve already seen cases where the timestamp is inaccurate. For example, if you rebind a DLL, then the rebound DLL has the same timestamp as the original, rather than the timestamp of the rebind, because you don’t want to break the bindings of other DLLs that bound to your DLL.

So the timestamp is already unreliable.

The timestamp is really a unique ID that tells the loader, “The exports of this DLL have not changed since the last time anybody bound to it.” […]

Raymond Chen – Why are the module timestamps in Windows 10 so nonsensical?

Bottom line: even though nobody had the intention to tamper with a timestamp, it may already be unreliable in certain cases.

Additional timestamps found in the PE file format

In addition to the field TimeDateStamp of the COFF File Header, there are further places where we can find possible compilation timestamps in PE files.

I think the most complete listing was compiled by Walied Assar. He lists additional places in the PE format where we can find possible compilation timestamps. I’ll refer only to the ones that can be used in order to determine the compilation time in the following sections.

Nevertheless, you should have a look at the other possible fields that Walied Assar’s aforementioned article mentions. Just for completeness, I’ll list the directories that I do not include in the following:

TimeDateStamp in _IMAGE_IMPORT_DESCRIPTOR (see _IMAGE_EXPORT_DIRECTORY; used in bound imports)
TimeDateStamp in _IMAGE_BOUND_IMPORT_DESCRIPTOR (see _IMAGE_EXPORT_DIRECTORY; used in bound imports)
TimeDateStamp in _IMAGE_LOAD_CONFIG_DIRECTORY (obsolete since Windows XP)

_IMAGE_EXPORT_DIRECTORY

The export directory (_IMAGE_EXPORT_DIRECTORY) of the PE format contains also a field called TimeDateStamp. Not all linkers seem to fill this field but Microsoft Visual Studio linkers fill it for both DLL and EXE PE files. For reference, the export directory structure _IMAGE_EXPORT_DIRECTORY is defined as follows:

typedef struct _IMAGE_EXPORT_DIRECTORY {
    DWORD Characteristics;
    DWORD TimeDateStamp;
    WORD MajorVersion;
    WORD MinorVersion;
    DWORD Name;
    DWORD Base;
    DWORD NumberOfFunctions;
    DWORD NumberOfNames;
    DWORD AddressOfFunctions;
    DWORD AddressOfNames;
    DWORD AddressOfNameOrdinals;
  } IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;

The field TimeDateStamp is relevant for bound imports as other PE files that use bound imports (see Import Binding) refer to the value of this field in their own field TimeDateStamp of IMAGE_IMPORT_DESCRIPTOR. Or in other words: the linker fills the field TimeDateStamp of IMAGE_IMPORT_DESCRIPTOR with the value of TimeDateStamp of _IMAGE_EXPORT_DIRECTORY of the PE file that they bind their import to. This is the reason why the field TimeDateStamp of IMAGE_IMPORT_DESCRIPTOR are unusable to determine a possible compilation date.

The value of this field describes the time when the export directory was created. Therefore, it doesn’t have to be equal to the TimeDateStamp from the COFF File Header. But it is often equal or very close to it.

_IMAGE_RESOURCE_DIRECTORY

Another TimeDateStamp field resides in the resource directory (_IMAGE_RESOURCE_DIRECTORY). The corresponding structure is defined as follows:

typedef struct _IMAGE_RESOURCE_DIRECTORY {
     DWORD   Characteristics;
     DWORD   TimeDateStamp;
     WORD    MajorVersion;
     WORD    MinorVersion;
     WORD    NumberOfNamedEntries;
     WORD    NumberOfIdEntries;
 } IMAGE_RESOURCE_DIRECTORY, *PIMAGE_RESOURCE_DIRECTORY;

While Microsoft Visual Studio linkers seem not to set this field, (old) Borland linkers set it. This is especially relevant for malware that is compiled with a Delphi version between Delphi 4 and Delphi 2006. As we later see, there is a known bug so that these versions do not correctly set the field TimeDateStamp of the COFF File Header. However, they set it – if the PE file comprises resources – in the IMAGE_RESOURCE_DIRECTORY and its subdirectories.

_IMAGE_DEBUG_DIRECTORY

If the linker emits debug information (/DEBUG), then the PE file contains an array of debug directories (_IMAGE_DEBUG_DIRECTORY). The corresponding structure contains a field called TimeDateStamp and is defined as follows:

typedef struct _IMAGE_DEBUG_DIRECTORY {
     DWORD   Characteristics;
     DWORD   TimeDateStamp;
     WORD    MajorVersion;
     WORD    MinorVersion;
     DWORD   Type;
     DWORD   SizeOfData;
     DWORD   AddressOfRawData;
     DWORD   PointerToRawData;
 } IMAGE_DEBUG_DIRECTORY, *PIMAGE_DEBUG_DIRECTORY;

As a PE file can contain several _IMAGE_DEBUG_DIRECTORYs (stored in an array), it is worth to check all of them, in case the timestamp of the first seems to be forged.

Furthermore, one type of debugging information contains a timestamp. The field Type holds several constants (range 0x0 – 0x9) that indicate the format of the debugging information. If the field is set to IMAGE_DEBUG_TYPE_CODEVIEW (0x2), then we can follow PointerToRawData of _IMAGE_DEBUG_DIRECTORY and we’ll find the CodeView information.

The relevant structures _CV_HEADER and _CV_INFO_PDB20 are defined as follows:

#define CV_SIGNATURE_NB10 '01BN'       
#define CV_SIGNATURE_NB09 '90BN'       
                
typedef struct _CV_HEADER               
{       
 DWORD dwSignature;       
 DWORD dwOffset;       
} CV_HEADER, *PCV_HEADER;       
                
typedef struct _CV_INFO_PDB20       
{       
 CV_HEADER CvHeader;       
 DWORD dwSignature;       
 DWORD dwAge;       
 BYTE PdbFileName[];       
} CV_INFO_PDB20, *PCV_INFO_PDB20;

If the _CV_HEADER‘s signature in dwSignature equals CV_SIGNATURE_NB10, then the PDB format is 2.0. In this case, the dwSignature contains an epoch value describing when the debug information was created. If it is not in PDB format, then dwSignature may comprises an unique identifier for each build. Note that the field dwAge is not a timestamp in epoch but rather an ever-increasing value that indicates an update to the PDB information.

Special cases

There are several noteworthy special cases where the timestamps are either not reliable or other timestamps should be preferred. The following sections will look into three of these cases and show possible ways to circumvent this limitation.

Delphi timestamps

Do you know what happened on 1992-06-19? I googled it and found out that this was the day Batman Returns was released in the USA. But that’s only relevant for Batman fans and not really related to timestamps. Something different happened, at least, if you believe the PE timestamps of likely thousands or even millions of Delphi binaries. They all were built on 1992-06-19 22:22:17. The timestamp value is 0x2A425E19 (708992537).

What sounds like a very productive programmer evening is actually a bug in many Delphi compiler versions. Delphi versions before Delphi 2007 (likely Delphi 4 – Delphi 2006) did not set the field TimeDateStamp at all. It seems that they just used a preconfigured value for this field. Maybe they used a PE stub that they filled out accordingly. However, there is a way to determine the real compilation timestamp of these binaries. If the sample comprises a resources directory (_IMAGE_RESOURCE_DIRECTORY), we can read its TimeDateStamp field instead. But be aware that the value is not an epoch timestamp but a MS DOS timestamp.

Bottom line: if you see a binary with a timestamp value of 1992-06-19 22:22:17, then you are likely dealing with a Delphi binary that was compiled with a Delphi version before Delphi 2007. If there are resources, then you may get at least a compilation estimate from the timestamp found in _IMAGE_RESOURCE_DIRECTORY.

Windows 10 reproducible builds timestamps

Windows 10 timestamps are nonsensical since Microsoft moved towards reproducible builds. In a nutshell, a reproducible build means starting a build from the exact same source code yields the exact same binary code. Obviously, timestamps are one obstacle in the way to reproducible builds. Therefore, timestamps are set to the hash of the resulting binary, which preserves reproducibility.

Let’s have a look at a Windows 10 binary to verify this behavior. For instance, regedit.exe comprises a TimeDateStamp value 0xBB9B6911 as can be seen in the following screenshot (using the tool pestudio). If we translate this value to UTC time, then this date would be way in the future. As expected, the TimeDateStamp value of Windows 10 binaries is unreliable.

Even though I am not aware of a way to get a compilation timestamp directly from these binaries, there are two possible ways to get at least an approximation. First, if the file was scanned at VirusTotal, then it must be older than the first submission date. This may be a very inaccurate approximation but a good starting point.

Second, a better way to approximate the age of the binary would be to use a binary index like Winbindex. For instance, here we can check if it indexes the regedit.exe file from the previous example. And indeed: Winbindex lists this regedit.exe file with sha256 hash d5de45decfd0fa08ac12f5725dfc7e5af1e3ed0325559101990fdcf02c439441 and states that it is part of Windows 10 1903 and 1909. So the earliest we can get is 2019-05-21, which is the release date of Windows 10 1903.

Gozi2 / ISFB timestamps

Gozi2 / ISFB and its forks are wide-spread malware strains. Malware analysts are likely to stumble upon one or more of them during their career. Even though the timestamps of a Gozi / ISFB sample may be forged, there is a “feature” of this malware family and many of its forks that is likely more reliable. As stated by Maciej Kotowicz in his report on ISFB:

One of first operations of all ISFB’ variants is to decode strings that are stored in .bss section, section that is normally used to keep non-initialized global variables. The algorithm used for string encoding is quite simple, it is a rolling xor with a compilation date as a key.

ISFB: Still Live and Kicking by Maciej Kotowicz

Again, the old rule of thumb holds here: threat actors are often as lazy as we are. Therefore, they will not touch this “feature”. We can see this in an ISFB fork called LOLSnif. The sample that was observed in campaigns in April 2020 loaded the plaintext key “Apr 1 2020” to decrypt its strings.

Threat actors who compile their malicious binaries can easily tamper with any of the aforementioned timestamp values. I would say that forging timestamps is a low-hanging fruit and not doing so shows a lack of or disinterest in Operational Security (OPSEC), respectively.

As a rule of thumb: you should never blindly trust the timestamp found in any of the TimeDateStamp fields as they can easily be forged! However, you can increase the confidence that you have in the correctness of this value by, for instance, correlating this with intrusion dates obtained from incident response engagements or metadata obtained from sources like VirusTotal (e.g. First Submission). Furthermore, you should never trust the TimeDateStamp value of packed binaries as this is one of the PE header fields that packers tamper with in the first place. However, the TimeDateStamp values of unpacked binaries are in many cases (but certainly not all!) correct as threat actors often do not care about tampering with it.

Case study: custom loader DLLs used in SUNBURST attacks

For instance, the threat actor who is responsible for the sophisticated supply chain attack known as SUNBURST forged timestamps as stated in Microsoft’s report “Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop“:

The custom loader DLLs dropped on disk carried compile timestamps ranging from July 2020 to October 2020, while the embedded Reflective DLLs carried compile timestamps ranging from March 2016 to November 2017. The presence of 2016-2017 compile timestamps is likely due to attackers’ usage of custom Malleable C2 profiles with synthetic compile timestamp (compile_time) values. At first glance it would appear as if the actor did not timestamp the compile time of the custom loader DLLs (2020 compile timestamps). However, forensic analysis of compromised systems revealed that in a few cases, the timestamp of the custom loader DLLs’ introduction to systems predated the compile timestamps of the custom loader DLLs (i.e., the DLLs appear to have been compiled at a future date).

Microsoft Security – Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop

The interesting point here is that both the loader DLLs as well as the CobaltStrike Beacons have forged timestamps. The timestamps of the CobaltStrike Beacons were likely forged as part of the CobaltStrike framework and carried timestamps way in the past. However, the interesting thing here is that the outer layer – the custom loader DLLs – carried timestamps that laid in the future.

Even though it might be wild speculation why these timestamps predated the actual intrusion dates, one possible explanation is that the threat actor wanted the intrusion to appear to last less time than it actually lasted, in case the loader DLLs would have been found by the local network defenders.

Read PE timestamps

Numerous tools and (Python) modules allow us to read (and modify) several fields of the PE header that can hold (compilation) timestamps. The following sections will show how these timestamps can be read with tools that I deem important. The first tools serve for manual inspection of individual PE files. But the later sections will show how to use two well-known Python modules in order to automate the PE timestamp extraction as a means of analyzing several PE files of a campaign / a threat actor.

Note that there is also an issue with several tools. While some display the TimeDateStamp as UTC time, some localize the TimeDateStamp and display incorrect information. IMHO the correct way is to display timestamps as UTC time and additionally indicate the shift that is required so that it’s in the supposedly correct time zone.

Read PE timestamps with a PE file viewer

This one is a no-brainer. Every PE file viewer like, for instance, PE Tree, pestudio, or PE-bear displays the aforementioned TimeDateStamp fields as seen in the following screenshot using PE Tree. Note how PE Tree correctly displays the TimeDateStamp field as UTC time.

Walied Assar wrote a tiny command line program called TimeDateStamp. This command line program inspects half of a dozen timestamps that are defined in the PE format. Use the -f flag with a path to a PE file as follows:

C:\Users\USER\Desktop>TimeDateStamp.exe -f yara64.exe
     TimeDateStamp from _IMAGE_FILE_HEADER        ---> Fri Jun 26 08:37:17 2020
     TimeDateStamp from _IMAGE_EXPORT_DIRECTORY   ---> Empty
     TimeDateStamp from _IMAGE_DEBUG_DIRECTORY    --->
     TimeDateStamp from _IMAGE_LOAD_CONFIG_DIRECTORY ---> Empty    

Another neat feature is that we can input a hex value (with or without leading 0x) and the tool spits out the corresponding date. For instance, if we input 0x2A425E19 (do you still remember what that was?), then it spits out Fri Jun 19 22:22:17 1992 correctly:

C:\Users\USER\Desktop>TimeDateStamp.exe 2A425E19
 Fri Jun 19 22:22:17 1992

Read PE timestamps with an hex editor

Daniel Plohmann’s tweet with a list of DWORDs with only the most significant byte set and their corresponding dates is particularly interesting. For those who work frequently with HexEditors inspecting binary formats (not necessarily the PE format), this table is very helpful. Based on the most significant byte of the timestamp DWORD, we can quickly estimate the date.

For instance, the Delphi timestamp 0x2A425E19 falls in the bin 0x2A000000 and 0x2B000000, or for humans 1992-04-30 14:11:12 and 1992-11-10 17:31:28. Note that each bin covers more or less six months.

I’ve generated the bins for 2015 – 2025, which should be the most relevant as of 2021:

U -> 0x55000000 - 2015-03-11T09:42:40
 V -> 0x56000000 - 2015-09-21T15:02:56
 W -> 0x57000000 - 2016-04-02T19:23:12
 X -> 0x58000000 - 2016-10-13T23:43:28
 Y -> 0x59000000 - 2017-04-26T04:03:44
 Z -> 0x5a000000 - 2017-11-06T07:24:00
 [ -> 0x5b000000 - 2018-05-19T12:44:16
 \ -> 0x5c000000 - 2018-11-29T16:04:32
 ] -> 0x5d000000 - 2019-06-11T21:24:48
 ^ -> 0x5e000000 - 2019-12-23T00:45:04
 _ -> 0x5f000000 - 2020-07-04T06:05:20
 ` -> 0x60000000 - 2021-01-14T09:25:36
 a -> 0x61000000 - 2021-07-27T14:45:52
 b -> 0x62000000 - 2022-02-06T18:06:08
 c -> 0x63000000 - 2022-08-19T23:26:24
 d -> 0x64000000 - 2023-03-02T02:46:40
 e -> 0x65000000 - 2023-09-12T08:06:56
 f -> 0x66000000 - 2024-03-24T11:27:12
 g -> 0x67000000 - 2024-10-04T16:47:28
 h -> 0x68000000 - 2025-04-16T21:07:44
 i -> 0x69000000 - 2025-10-28T00:28:00

Read PE timestamps from the command line

There are many command line tools that can read the PE header. One tool I like to use is readpe from the pev toolkit. pev is open source, works on several platforms, and comes with many handy tools when dealing with PE files from the command line. Let’s just use readpe to read the field TimeDateStamp of the COFF File Header from a packed IcedId PhotoLoader sample (4e7161be03f206c1b086bb15b47470ec1c9381302eb34d0e76915496aec77193, first submission to VT: 2020-05-27 23:31:27).

We call readpe with the -h flag, which allows us to specify a header that we would like to inspect. For our purpose, this is the COFF header (coff). As a result, readpe dumps all fields from this header.

readpe -h coff 4e7161be03f206c1b086bb15b47470ec1c9381302eb34d0e76915496aec77193
COFF/File header
     Machine:                         0x14c IMAGE_FILE_MACHINE_I386
     Number of sections:              4
     Date/time stamp:                 1432567928 (Mon, 25 May 2015 15:32:08 UTC)
     Symbol Table offset:             0
     Number of symbols:               0
     Size of optional header:         0xe0
     Characteristics:                 0x103
     Characteristics names
                                          IMAGE_FILE_RELOCS_STRIPPED
                                          IMAGE_FILE_EXECUTABLE_IMAGE
                                          IMAGE_FILE_32BIT_MACHINE

However, the timestamp is forged since the first submission of this sample was in Spring 2020 but the timestamp says that the sample is from Spring 2015. Let’s unpack the sample with unpac.me and we receive one unpacked child (70fe6ccca21ce51800c7b998e8fc06997eac07e086f1dcdd87765b2dcea72395):

readpe -h coff 70fe6ccca21ce51800c7b998e8fc06997eac07e086f1dcdd87765b2dcea72395
COFF/File header
     Machine:                         0x14c IMAGE_FILE_MACHINE_I386
     Number of sections:              5
     Date/time stamp:                 1586956141 (Wed, 15 Apr 2020 13:09:01 UTC)
     Symbol Table offset:             0
     Number of symbols:               0
     Size of optional header:         0xe0
     Characteristics:                 0x102
     Characteristics names
                                          IMAGE_FILE_EXECUTABLE_IMAGE
                                          IMAGE_FILE_32BIT_MACHINE

Now, this timestamp looks much better. It is likely to be the correct compilation timestamp of this sample due to the first submission to VT differs just one month. Furthermore, there is a blog post published at the end of April 2020 that described this new variant of IcedId’s PhotoLoader.

Read PE timestamps with pefile

pefile is a Python module to parse and modify PE files. The following script (based on this blog post) shows how to read the field TimeDateStamp from the COFF File Header and convert it to UTC time. In addition, it prints out how old the PE file is. Note that accessing other TimeDateStamp fields as described in Section “Additional timestamps found in PE files” works similarly. Please refer to the usage examples of pefile.

import datetime
import pefile
import sys

pe = pefile.PE(sys.argv[1])
ts = int(pe.FILE_HEADER.dump_dict()['TimeDateStamp']['Value'].split()[0], 16)
utc_time = datetime.datetime.utcfromtimestamp(ts)
t_delta = (datetime.datetime.today() - utc_time).days
print(utc_time.strftime("%Y-%m-%d %H:%M:%S +00:00 (UTC)") + f" ({t_delta} days old)")

If we run this simple script on a Delphi sample (Wabot, ebf6d5d12f4d18cef9456a363991ba028329cd25ee3908101c6c5aa624f21265), then we get a somewhat surprising result:

python get_timestamp_pefile.py ebf6d5d12f4d18cef9456a363991ba028329cd25ee3908101c6c5aa624f21265
1992-06-19 22:40:53 +00:00 (UTC) (10436 days old)

The value is 0x2A426275, which translates to 1992-06-19 22:40:53. This is not the expected Delphi timestamp 0x2A425E19. The most significant two bytes are equal (0x2A42), but the least significant two bytes / WORD is different. A possible explanation is that the timestamp was modified.

Read PE timestamps with lief

lief is another project to parse and modify PE files. Its core is written in C++ but there is a Python module as well. In contrast to pefile, lief can parse various executable formats such as ELF and MachO while offering the same interface. Therefore, lief works well in projects that do not only target one platform. Furthermore, lief added several advanced features not yet implemented in pefile like working with PE Authenticode.

Read COFF File Header timestamps

The following code snippet shows the script get_timestamp_lief.py that reads the PE Header field TimeDateStamp (called by lief time_date_stamps) and converts it to UTC time (analogous to the pefile script of the previous section). Just import the module lief and open the binary with the parse method. The COFF File Header is accessible via header and the field TimeDateStamp is called time_date_stamps in lief.

import datetime
 import lief
 import sys
 binary = lief.parse(sys.argv[1])
 ts = binary.header.time_date_stamps
 utc_time = datetime.datetime.utcfromtimestamp(ts)
 t_delta = (datetime.datetime.today() - utc_time).days
 print(utc_time.strftime("%Y-%m-%d %H:%M:%S +00:00 (UTC)") + f" ({t_delta} days old)")

Read Delphi timestamps

Again, Delphi binaries that were compiled with Delphi 4 – Delphi 2006 had a bug: all of them had the same TimeDateStamp value in the COFF File Header. However, there is a way (as described by Hexacorn) to get the compilation timestamp via the field TimeDateStamp in the resource directory (_IMAGE_RESOURCE_DIRECTORY). Be aware that in Delphi binaries this field does not hold an epoch timestamp but rather a MS DOS timestamp.

The following script reads a possible compilation timestamp for Delphi binaries. It borrows the function from_msdos from the project Time Decode to convert the MS DOS timestamp to a readable string. First, it checks if the TimeDateStamp field of the IMAGE_FILE_HEADER equals the expected Delphi timestamp (seen in Delphi 4 – Delphi 2006 binaries) in lines 26 – 27. In this case, it checks if there are resources with binary.has_resources in line 29 and then gets resource directory with binary.resources in line 30. Finally, it gets the timestamp and converts it from MS DOS format to a readable string.

import datetime
 import lief
 import sys

 def from_msdos(msdos):
     """taken from https://github.com/digitalsleuth/time_decode"""
     msdos = hex(msdos)[2:]
     binary = '{0:032b}'.format(int(msdos, 16))
     stamp = [binary[:7], binary[7:11], binary[11:16], binary[16:21], binary[21:27], binary[27:32]]
     for val in stamp[:]:
         dec = int(val, 2)
         stamp.remove(val)
         stamp.append(dec)
     dos_year = stamp[0] + 1980
     dos_month = stamp[1]
     dos_day = stamp[2]
     dos_hour = stamp[3]
     dos_min = stamp[4]
     dos_sec = stamp[5] * 2
     if (dos_year in range(1970,2100)) or not (dos_month in range(1,13)) or not (dos_day in range(1,32)) or not (dos_hour in range(0,24)) or not (dos_min in range(0,60)) or not (dos_sec in range(0,60)):
         dt_obj = datetime.datetime(dos_year, dos_month, dos_day, dos_hour, dos_min, dos_sec)
         return dt_obj.strftime('%Y-%m-%d %H:%M:%S')
     return "Not a valid MS DOS timestamp"

 binary = lief.parse(sys.argv[1])
 ts = binary.header.time_date_stamps
 if ts == 0x2a425e19:
     print('Found binary compiled with Delphi 4 - Delphi 2006')
     if binary.has_resources:
         root = binary.resources
         if root.time_date_stamp != 0:
             ts = root.time_date_stamp
             dos_time = from_msdos(ts)
             print(f'_IMAGE_RESOURCE_DIRECTORY: {hex(ts)} -> {dos_time}')
         else:
             print('Timestamp of _IMAGE_RESOURCE_DIRECTORY is set to zero')
     else:
         print('Binary has no resources.')
 else:
     utc_time = datetime.datetime.utcfromtimestamp(ts)
     print('Likely not a binary compiled with Delphi 4 - Delphi 2006')
     print(hex(ts) + ' -> ' + utc_time.strftime("%Y-%m-%d %H:%M:%S +00:00 (UTC)"))

I tested it with an older Azorult (version 3.1) sample:

> python lief_delphi_ts.py azor3.1_patched_fixed.pe32                                                 
Found binary compiled with Delphi 4 - Delphi 2006
 _IMAGE_RESOURCE_DIRECTORY: 0x4cbe1371 -> 2018-05-30 02:27:34

This looks a lot better. First, it matches the Delphi timestamp in the COFF File Header as expected. Luckily, there are resources and hence a _IMAGE_RESOURCE_DIRECTORY struct. The date 2018-05-30 seems to be a reasonable compilation timestamp for an Azorult version 3.1 sample.

What can we do with PE timestamps?

Now that we know where we can find PE timestamps and how we can read them using a wide range of tools, this section answers the final question: what can we do with PE timestamps? The following sections should inspire what we can do with them but also warn you once more that relying solely on this feature alone can certainly be very misleading.

Use case: Determine probable intrusion date

If timestamps found in PE files were always reliable, they could be used to determine probable intrusion dates, especially if you are an observer on the outside. For instance, it is common to hunt for ransomware samples on online cloud services like VirusTotal as these samples contain information that can identify the possible victim.

For instance, CL0P ransomware timestamps are reliable. Firstly, incident response engagements suggest this. Secondly, the temporal correlation between the sample timestamps, the first submission to VirusTotal, and the publication of the victim’s data on their leak portal seem to be in line. If you combine these factors then you can likely estimate the deployment date of the ransomware from the outside.

Nevertheless, this is in theory not limited to ransomware deployments. PE timestamps of samples that were used in a certain intrusion (possible one in the interest of the public domain) can be utilized to estimate the intrusion dates of nation-state actors like Winnti. Samples of Winnti typically contain information such as a C&C domain and a campaign ID that can be used to guess possible victims. In addition, PE timestamps seem to be reliable to a certain degree to estimate at least the year of the intrusion.

Use case: Timeline of threat actor’s campaigns and threat actor’s working hours

As stated by Bartholomew & Guerrero-Saade in their exceptional paper “Wave your false flags!“, timestamps allow for creating a timeline of a threat actor’s campaigns or deduce their working hours:

A great benefit of the Portable Executable file format is the inclusion of compilation times. Though these can be altered with ease, many samples include original timestamps. Beyond an obvious indication of an actor’s longevity, timestamps allow for an understanding of specific campaigns as well as the evolution of an actor’s toolkit throughout the years. With a large enough collection of related samples, it’s also possible to create a timeline of the campaign operators’ workday. Where these operate in any professional setting or with any semblance of discipline, it’s possible to match the normal peaks and troughs of a workday and pinpoint a general timezone for their operations.

Bartholomew & Guerrero-Saade – Wave your false flags!

There are at least two commonly plot types possible based on the PE timestamps:

timeline of the malware samples/families (see Page 32 of Mandiant’s APT1 report for a great example)
heatmap by day of week and hour of day (similar to the ones typically found in web traffic analysis)

Bartholomew & Guerrero-Saade stated “With a large enough collection of related samples” all these cool things can be done. Honestly, I don’t have a large number of samples for this blog post at hand. Nevertheless, I’ve plotted a tiny timeline of the different SDBBot versions published (based on the PE timestamps) in Summer 2020. The samples are on MalwareBazaar.

Of course, the is room for improvement, and not speaking of the horrible design. For instance, we could plot tiny red dots on the X-axis for every day the threat actor was active. In this case, this should give us a workday / weekend pattern.

Use case: Pinpoint a threat actor to a timezone

The previous section mentions that the timezone of a threat actor can be pinpointed based on PE timestamps. In order for this to work out, there are two requirements:

“large enough collection of related samples” that we can attribute to the threat actor without a doubt
certain confidence that the threat actor did not tamper with the PE timestamps

It is likely that the PE timestamps fall into a certain range if the threat actor works in a professional environment with regular office hours. Likely, most samples will be compiled within an 8 to 12 hours range, which maps to a 9 to 5 pattern plus/minus two hours. Furthermore, there are likely one or two days off like Saturday or Sunday. But this might depend on the cultural origin of the threat actor. For instance, 996 working hour system is common in the People’s Republic of China. In addition, there could also be thirty minutes and up to two hours of lunch breaks.

If you can identify such a pattern, then you add/subtract the difference of hours so that this maps to the 9 AM to 5 PM range of a timezone. In case your plot does not reveal a 9 to 5 pattern, then there are still possible explanations. In case you can see two possible 9 to 5 patterns then this could indicate shift work.

Finally, another warning example of why you should not blindly trust PE timestamps. Imagine that you’ve dozens of samples of a threat actor. You are pretty confident that this threat actor works normal working hours from 9 AM to 5 PM (GMT+0). You could assume that this threat actor may work in the United Kingdom or in Portugal if you blindly and solely rely on these timestamps.

Suppose that later on, you’ve got additional information from incident response engagements. Now, it seems that the threat actor works from 12 PM to 8 PM (GMT+0). This would map from 9 AM to 5 PM (GMT+3). Possible countries would now be, for instance, Russia or Turkey. How can you really be sure that the threat actor did not manipulate the PE timestamps and subtracted three hours from each and every timestamp found in the PE files?

Where to start tracking adversary infrastructure?

Fri, 15 Jan 2021 22:18:33 +0000

Reviewed July 2026: This resource list is kept for historical and conceptual value. Individual services, links, and company names may have changed since publication.

Adversaries require infrastructure to support their operations and to ultimately achieve their goals like intelligence collection. Therefore, infrastructure is one of the four core features of the famous Diamond Model of Intrusion Analysis. The proactive detection of adversary infrastructure can help cyber threat intelligence (CTI) teams detect this infrastructure even before the adversary has utilized it.

The quintessence here is that we are all lazy humans with our personal preferences and tendencies. Therefore, operational security (OpSec) is sometimes neglected for greater comfort. Tracking adversary infrastructure is based on the idea that we take data from past intrusions, identify patterns, which we then search for in the future. This initial data from past intrusions may be primary source data from incident response engagements or secondary source data from CTI blogs. Today, there are numerous sources that we can leverage to detect future adversary infrastructure: either we rely on third-party services like Shodan or Censys, to name a few, or we can run our own scanning infrastructure using, for instance, MASSCAN.

This blog post lists curated resources for tracking adversary infrastructure. The first section Infrastructure tracking basics lists introductory resources to get started. The next section Examples of infrastructure tracking comprises a list of read-worthy resources that showcase how to use the techniques described in the previous section. The third section Infrastructure tracking automation gives an overview of resources for those who wish to automate parts of the tracking process. Finally, I’ll present a list of (open source) tools and online services that are essential for this endeavor.

Advanced Persistent Infrastructure Tracking by Nils Kuhnert @ Censys Blog: This should be the first introductory article you read before you start tracking adversary infrastructure. It gives you the background on why this actually works, e.g. different teams with different skillsets set up the infrastructure and operate it. Using the online service Censys as an example, it shows how to use HTTP headers to track CobaltStrike infrastructure in general and certificate data to track APT29’s infrastructure. The blog post concludes with a bunch of useful tips for beginners.
Analyzing Network Infrastructure as Composite Objects by Joe Slowik / Domains Tools Blog: Good introductory post on malicious network infrastructure, mostly focusing on domain names, IP addresses, and SSL/TLS certificates. It encourages analysts not to treat these types of IoCs as atomic objects but rather as composite objects. CTI analysts should see the identification of new IoCs as an intermediate objective and leverage them for their long-term objective of understanding an adversary’s behavior and tendencies.
Extrapolating Adversary Intent Through Infrastructure by Joe Slowik / Domains Tools Blog: Often adversaries leverage themes in domain creation. For instance, this may help them to blend in with expected traffic on their victims’ networks (e.g. Microsoft-themed domain names). In this blog post, three case studies show how important the themes of domain names are. By studying them, we can infer the intentions and purposes of the adversary.
Attribution of Advanced Persistent Threats: How to Identify the Actors Behind Cyber-Espionage (ISBN: 978-3662613122) by Timo Steffens: This book is the most comprehensive resource on threat actor attribution. Of course, infrastructure plays an important role in attribution. Therefore, a whole chapter is dedicated to this topic (Chapter 4). Personally, I would recommend this book to every CTI analyst.

Examples of infrastructure tracking

There are several blog posts that prove that tracking adversary infrastructure works. It doesn’t matter if it’s APT or cybercrime infrastructure. The following are read-worthy articles that show how to apply the acquired knowledge to real-world data.

APT1- Exposing One of China’s Cyber Espionage Units by Mandiant: This report originally published in 2013 was unprecedented. It showed that a private-sector entity can deliver a very precise attribution of a nation-state actor. Furthermore, it introduced the three magical letters A-P-T to a wider audience. I believe that every CTI analyst should read this report, alone due to its historical value. The infrastructure tracking part starts on page 39 and comprises 11 pages.
Analyzing Cobalt Strike for Fun and Profit by Etienne Maynier @ randhome.io: This article shows how the fingerprinting tools JARM and Shodan can be combined in order to unearth a significant part of live CobaltStrike CC servers. The servers are then contacted, Beacons are downloaded, and configuration information is extracted.
Identifying Critical Infrastructure Targeting through Network Creation by Joe Slowik / Domains Tools Blog: This blog post shows how to use previous findings from other researchers in order to pivot on them to find further infrastructure. They focus on the infrastructure of APT34 / OilRig. At first, they pivot on email addresses that this actor utilized to register domains. One of the email addresses registered several domains that follow certain patterns, e.g. mimicking corporate/executive themes or referring to the People’s Republic of China (PRC). Pivoting on these domains allowed them to find further emails sent from this aforementioned infrastructure in several malware repositories. Subsequently, they unveiled a previously unknown phishing campaign. Even though there is no final conclusion on whether this is a related or completely separated phishing campaign, this finding may help other researchers in their future investigations.
Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin’s Most Dangerous Hackers (ISBN: 978-0525564638) by Andy Greenberg: Even though this is a nonfiction but also nontechnical book, it is a good read for long and cold winter evenings with some tracking of adversary infrastructure. This book tells the story of the hunt for the nation-state actor Sandworm, who is responsible for many high-profile cyber operations in recent history. Many reputable CTI analysts tell their part of their story.

Infrastructure tracking automation

SCANdalous by Aaron Stephens, Andrew Thompson / FireEye Threat Research Blog: SCANdalous is an in-house system of FireEye that proactively detects adversary infrastructure. However, the analyst is still in the loop. It is a very interesting example for those who wish to automate infrastructure tracking. Its main idea is to observe and collect data on adversaries (e.g. via incident response engagements), to identify patterns and characteristics (e.g. regarding the HTTP headers), to craft queries (e.g. for Shodan), and to monitor new results over time. There are also a video presentation and slides.

Tools

Nmap: Nmap is a network scanner that discovers hosts, scans ports, and detects service versions as well as operating systems. It comprises a scripting engine called Nmap Scritping Engine (NSE). There are already many NSE scripts available, for instance, to detect Winnti infections or grab CobaltStrike Beacon configurations. While versatile and well supported, it is not a solution to conduct mass scans. It is rather useful to, for example, scan suspicious hosts obtained from services like Shodan.
MASSCAN: MASSCAN is an Internet-scale port scanner. It is blazing fast so that it can transmit up to 10 million packets per second. Under the hood, MASSCAN transmits packets asynchronously and comes with its own TCP/IP stack. While it is great to conduct superficial scans of many machines, it is not suited for in-depth scans like Nmap.
JARM: JARM is a tool for active fingerprinting of Transport Layer Security (TLS) server. There is a blog post that goes into the details of JARM’s inner workings. Several online services like Shodan have added support for JARM. A great example of how to combine JARM and Shodan is Analyzing Cobalt Strike for Fun and Profit.

Online services

The following online services are essential tools for tracking adversary infrastructure. It is very unlikely that you have these capabilities in-house. Most of them offer free researcher accounts that usually come with a (very) limited daily quota. Nevertheless, this is sufficient for starters or for those who track only one or two adversaries very closely. Especially if you are planning to automate the tracking process, you require paid accounts with larger daily quotas.

Search engines

Shodan: Shodan crawls the Internet for publicly accessible devices and lets its users search within this data. Search queries over the web interface allow many modifiers, but their real power lies in its REST API. There is also a Python library for this search engine.
Censys: Censys offers a quite comprehensive view of the current state of the Internet. It allows searching for IPv4 hosts, domains, and certificates. There is of course a REST API to automate searches.
BinaryEdge: BinaryEdge is another service that offers a vast amount of Internet-wide data to search in. Naturally, they offer a REST API for automation purposes.

Passive Databases

RiskIQ PassiveTotal: PassiveTotal aggregates web data from different sources (e.g. passive DNS, WHOIS, SSL/TLS certificates). This (historical) data allows us to quickly pivot on these sources and identify further adversary infrastructure.
CIRCL Passive SSL: Passive SSL is a historical database with historical X.509 certificates seen per IP address. It is only accessible via its REST API but they offer also a Python library called pypssl.

The malware analyst's guide to aPLib decompression

Fri, 08 Jan 2021 06:00:00 +0000

Reviewed July 2026: This post is kept for the analysis workflow and file-format notes. External project links and tool versions may have changed since publication.

aPLib is a compression library that is very easy to use and integrate with C/C++ projects. It is a pure LZ-based compression library. There is also an executable packer based on it called aPACK. Due to its ease of use and tiny footprint, it’s a very popular library utilized by many malware families like ISFB/Ursnif, Rovnix, and many more. Knowledge about aPLib detection and aPLib decompression is crucial for every malware analyst.

This blog post dives into many internals of aPlib, explains how to detect aPLib compression with your bare eyes as well as YARA, and finally shows you how to decompress aPLib compressed blobs with several tools.

aPLib is a library implementing the compression algorithm found in the executable compressor aPACK. It is a pure LZ compression implementation. The library aPLib is known for its fast decompression speed and tiny footprint of the decompression code. At the time of writing, the current version was v1.1.1.

The objective of this section is not to explain how the actual compression algorithm at aPLib’s core works, but rather to give a quick overview of the library itself (project structure, relevant functions, relevant structs).

Since you’ll likely encounter aPLib decompression during malware analysis, I’ll focus on the decompression portion of aPLib in the following. Nevertheless, this blog post should be also valuable for those who look into aPLib compression.

The aPLib library

The library can be found at the author’s website. It comprises a lot of valuable information. First and foremost, there is the source code for decompression (but not compression!):

└── src
     ├── 32bit
     │   ├── crc32.asm
     │   ├── depack.asm
     │   ├── depackf.asm
     │   ├── depacks.asm
     │   ├── scheck.asm
     │   ├── sdepack.asm
     │   ├── sgetsize.asm
     │   └── spack.asm
     ├── 64bit
     │   ├── crc32.asm
     │   ├── depack.asm
     │   ├── depackf.asm
     │   ├── depacks.asm
     │   ├── scheck.asm
     │   ├── sdepack.asm
     │   ├── sgetsize.asm
     │   └── spack.asm
     ├── depack.c
     ├── depack.h
     ├── depacks.c
     └── depacks.h

Second, there is some additional user documentation (html and chm). Third, there are libraries to statically or dynamically link against. Several platforms are supported including Windows:

├── lib
 │   ├── dll
 │   │   ├── aplib.dll
 │   │   ├── aplib.h
 │   │   └── aplib.lib
 │   ├── dll64
 │   │   ├── aplib.dll
 │   │   ├── aplib.h
 │   │   └── aplib.lib

The library offers several decompression functions that fall in three classes:

aP_depack, aP_depack_asm, and aP_depack_asm_fast assume valid input data and may crash if the input is invalid
aP_depack_safe and aP_depack_asm_safe catch decompression errors and do not crash on invalid input data
aPsafe_depack is a function wrapper adding a header to the compressed data

At their core, they all utilize the LZ-based compression algorithm. In the following sections, I’ll have a look at each of the three classes.

aP_depack*

The decompression function aP_depack decompresses a compressed binary blob. The counterpart of aP_depack_safe is the function aPsafe_pack.

The following function signature is defined in depack.h:

unsigned int aP_depack(const void *source, void *destination);

The functions of this class assume that the compressed data is valid. This saves some sanity checks, which in turn results in faster decompression and a smaller footprint of the decompression code. However, it is likely that they crash if an error is encountered.

aP_depack_safe*

The functions of this class solely add additional sanity checks. If they encounter an error condition, they return APLIB_ERROR (defined as 0xFFFFFFFF). Furthermore, they require the length of the input (compressed data) and the size of the output (decompressed data) as seen in the signature of the aP_depack_safe function:

unsigned int aP_depack_safe(const void *source,
                             unsigned int srclen,
                             void *destination,
                             unsigned int dstlen);

Otherwise, they are equivalent to the functions from the aP_depack* class.

aPsafe_depack

The decompression function aPsafe_depack decompresses a compressed binary blob safely. It is a wrapper around the functions of the class. The counterpart of aPsafe_depack is the function aPsafe_pack.

The function signature of aPsafe_depack resembles the signature of aP_depack_safe:

unsigned int aPsafe_depack(const void *source,
                             unsigned int srclen,
                             void *destination,
                             unsigned int dstlen);

aPsafe_depack requires that the compressed blob starts with a header. This header comprises additional information regarding the blob. This is for example very useful if we want to send an aPLib compressed blob over the network. The header structure looks like the following struct:

struct aPLib_header {
DWORD tag;
DWORD header_size;
DWORD packed_size;
DWORD packed_crc;
DWORD orig_size;
DWORD orig_crc;
}

The struct aPLib_header has a size of 24 bytes. This holds on x86 and x64 systems. But there are several checks in the library that ensure that the header_size is at least 24 bytes. The following screenshot shows a PE executable packed with appack:

We can see the magic AP32 (0x32335041), directly followed by the header size of 0x18 / 24 bytes. The next four DWORDs are the packed_size, packed_crc, orig_size, and orig_crc. After the header comes the payload, which starts in this case with M8Z since we compressed a PE executable. We will use this fact later on for detection.

Detect if a binary statically links against aPLib

Detecting if a binary comprises the capability of aPLib compression/decompression is straightforward in the case it dynamically links against aPLib and it comprises a valid IAT (Import Address Table). However, in the case of custom/malicious binaries, it typically statically links against aPLib.

Still, there are many ways how we can detect this. First, we’ve already seen constants like AP32 (0x32335041), which we could leverage to detect aPLib. But there are also several strings present that refer to aPLib itself or its author (Jørgen Ibsen) as seen in the following screenshot:

These ASCII strings are:

“aPLib v1.1.1 – the smaller the better :)”
“Copyright (c) 1998-2014 Joergen Ibsen, All Rights Reserved.”
More information: http://www.ibsensoftware.com/

Another way would be detection via matching the assembly code. Tools like mkYARA can help you to generate (strict/relaxed) YARA rules for assembly functions/algorithms.

However, at this point, I do not want to reinvent the wheel and I just refer to one of the freely available YARA rules like the one from “_pusher_”:

rule aPLib : Jorgen Ibsen               
{             
 meta:        
 author="_pusher_"          
 date="2016-09"            
 description="www.ibsensoftware.com/products_aPLib.html"              
 strings:            
 $a0 = { 60 8B 74 24 24 8B 7C 24 28 8B 44 24 2C FC 33 DB B2 80 39 18 74 42 A4 B3 02 E8 6D 00 00 00 73 F6 33 C9 E8 64 00 00 00 73 }         
 $a1 = { 60 8B 74 24 24 8B 7C 24 28 FC 33 DB 33 D2 A4 B3 02 E8 6D 00 00 00 73 F6 33 C9 E8 64 00 00 00 73 1C 33 C0 E8 5B 00 00 00 }       
 $a3 = { B2 80 33 DB A4 B3 02 E8 6D 00 00 00 73 F6 33 C9 E8 64 00 00 00 73 1C 33 C0 E8 5B 00 00 00 73 23 B3 02 41 B0 10 E8 4F 00 00 00 12 C0 73 F7 75 3F AA EB D4 E8 4D 00 00 00 2B CB 75 10 E8 42 00 00 00 EB 28 AC D1 E8 74 4D 13 C9 EB 1C 91 48 C1 E0 08 AC E8 2C 00 00 00 3D 00 7D 00 00 }       
 $a4 = { 61 94 55 B6 80 A4 FF 13 73 F9 33 C9 FF 13 73 16 33 C0 FF 13 73 1F B6 80 41 B0 10 FF 13 12 C0 73 FA 75 3A AA EB E0 FF 53 08 02 F6 83 D9 01 75 0E FF 53 04 EB 24 AC D1 E8 74 2D 13 C9 EB 18 91 48 C1 E0 08 AC FF 53 04 3B 43 F8 73 0A 80 FC 05 73 06 83 F8 7F 77 02 41 41 95 8B C5 }         
 $a5 = { B2 80 A4 B6 80 FF 13 73 F9 33 C9 FF 13 73 16 33 C0 FF 13 73 1F B6 80 41 B0 10 FF 13 12 C0 73 FA 75 3C AA EB E0 FF 53 08 02 F6 83 D9 01 75 0E FF 53 04 EB 26 AC D1 E8 74 2F 13 C9 EB 1A 91 48 C1 E0 08 AC FF 53 04 3D 00 7D 00 00 73 0A 80 FC 05 73 06 83 F8 7F 77 02 }        
 $a6 = { B2 80 31 DB A4 B3 02 E8 6D 00 00 00 73 F6 31 C9 E8 64 00 00 00 73 1C 31 C0 E8 5B 00 00 00 73 23 B3 02 41 B0 10 E8 4F 00 00 00 10 C0 73 F7 75 3F AA EB D4 E8 4D 00 00 00 29 D9 75 10 E8 42 00 00 00 EB 28 AC D1 E8 74 ?? 11 C9 EB 1C 91 48 C1 E0 08 AC E8 2C 00 00 00 3D 00 7D 00 00 73 0A 80 FC 05 73 06 83 F8 7F 77 02 }       
 $a7 = { 33 C9 FF D3 73 16 33 C0 FF D3 73 23 B6 80 41 B0 10 FF D3 12 C0 73 FA 75 42 AA EB E0 E8 46 00 00 00 02 F6 83 D9 01 75 10 E8 38 00 00 00 EB 28 AC D1 E8 74 48 13 C9 EB 1C 91 48 C1 E0 08 AC E8 22 00 00 00 3D 00 7D 00 00 73 0A 80 FC 05 73 06 83 F8 7F 77 02 41 41 95 }       
 $a8 = { 33 C9 FF 14 24 73 18 33 C0 FF 14 24 73 21 B3 02 41 B0 10 FF 14 24 12 C0 73 F9 75 3F AA EB DC E8 43 00 00 00 2B CB 75 10 E8 38 00 00 00 EB 28 AC D1 E8 74 41 13 C9 EB 1C 91 48 C1 E0 08 AC E8 22 00 00 00 3D 00 7D 00 00 73 0A 80 FC 05 73 06 83 F8 7F 77 02 41 41 95 }       
 $a9 = { 33 C0 FF 13 73 1F B6 80 41 B0 10 FF 13 12 C0 73 FA 75 3A AA EB E0 FF 53 08 02 F6 83 D9 01 75 0E FF 53 04 EB 24 AC D1 E8 74 2D 13 C9 EB 18 91 48 C1 E0 08 AC FF 53 04 3B 43 F8 73 0A 80 FC 05 73 06 83 F8 7F 77 02 41 41 95 }       
 $a10 = { 60 8B 74 24 24 8B 7C 24 28 FC B2 80 33 DB A4 B3 02 E8 6D 00 00 00 73 F6 33 C9 E8 64 00 00 00 73 1C 33 C0 E8 5B 00 00 00 73 23 B3 02 41 B0 10 E8 4F 00 00 00 12 C0 73 F7 75 3F AA EB D4 E8 4D 00 00 00 2B CB 75 10 E8 42 00 00 00 EB 28 AC D1 E8 74 4D 13 C9 EB 1C 91 48 C1 E0 08 AC E8 2C 00 00 00 3D 00 7D 00 00 73 0A 80 FC 05 73 06 83 F8 7F 77 02 41 41 95 }       
 //taken from r!sc aspr unpacker,       
 $a11 = { B2 80 8A 06 46 88 07 47 02 D2 75 05 8A 16 46 12 D2 73 EF 02 D2 75 05 8A 16 46 12 D2 73 4A 33 C0 02 D2 75 05 8A 16 46 12 D2 0F 83 D6 00 00 00 02 D2 75 05 8A 16 46 12 D2 13 C0 02 D2 75 05 8A 16 46 12 D2 13 C0 02 D2 75 05 8A 16 46 12 D2 13 C0 02 D2 75 05 8A 16 46 12 D2 13 C0 74 06 57 2B F8 8A 07 5F 88 07 47 EB A0 B8 01 00 00 00 02 D2 75 05 8A 16 46 12 D2 13 C0 02 D2 75 05 8A 16 46 12 D2 72 EA 83 E8 02 75 28 B9 01 00 00 00 02 D2 75 05 8A 16 46 12 D2 13 C9 02 D2 75 05 8A 16 46 12 D2 72 EA 56 8B F7 2B F5 F3 A4 5E E9 58 FF FF FF 48 C1 E0 08 8A 06 46 8B E8 B9 01 00 00 00 02 D2 75 05 8A 16 46 12 D2 13 C9 02 D2 75 05 8A 16 46 12 D2 72 EA 3D 00 7D 00 00 73 1A 3D 00 05 00 00 72 0E 41 56 8B F7 2B F0 F3 A4 5E E9 18 FF FF FF 83 F8 7F 77 03 83 C1 02 56 8B F7 2B F0 F3 A4 5E E9 03 FF FF FF 8A 06 46 33 C9 D0 E8 74 12 83 D1 02 8B E8 56 8B F7 2B F0 F3 A4 5E E9 E8 FE FF FF 5D 2B 7D 0C 89 7D FC 61 }       
 condition:           
 any of them       
                }

Nevertheless, there is still the possibility that all strings are overwritten, constants like AP32 are changed or are dynamically computed. Just remember that having not a match does not rule out aPLib usage completely but it makes it very unlikely.

Detect aPLib compression with your bare eyes and YARA

The following three sections shows you how to detect aPLib compression with your bare eyes and suggest several YARA rules to automate detection.

aPLib header

If the compressed blob is safely packed, then it is quite easy to find them within larger blobs. All we need to do is looking for the aPLib magic AP32 and the default header size of 0x18:

This boils down to searching for the byte sequence 0x4150333218000000. We can write a quick and dirty YARA signature:

rule aplib_compressed_blob_with_header {
     meta:
         author = "Thomas Barabosch"
         version = "20200109"
         description = "Detects aPLib compressed blobs that comprise an aPLib header."
     strings:
         $aplib_compressed_with_header = { 41 50 33 32 18 00 00 00 }
     condition:
         $aplib_compressed_with_header
  }

Compressed PE executables without aPLib header

However, as a malware analyst, you will stumble upon aPLib compressed blobs that do not comprise an aPLib header very frequently. At least, the good news is that the trained eye can easily spot aPLib compressed PE files. These blobs of compressed PE files do not start with the classic MZ magic but with M8Z:

Once you know that M8Z means aPLib compression, it makes sense to write a small YARA signature to detect this in the future. Here I assume that we dumped a blob from, for instance, the heap, and the magic is at the beginning of the file:

rule aplib_compressed_pe {
     meta:
         author = "Thomas Barabosch"
         version = "20201226"
         description = "Detects aPLib compressed PE files, e.g. from memory dumps."
     strings:
         $mz_compressed = "M8Z"
     condition:
         $mz_compressed at 0
  }

Compressed ELF executables without aPLib header

Furthermore, I compressed a couple of ELF x64 files with appack. I wanted to see if there is also a pattern that gives aPLib compression away. If we byte-compare the output of two compressed files, then we will see the following:

Both compressed blobs start with the same AP32 magic and the default header size of 0x18. Of course, the next four DWORDs are the packed_size, packed_crc, orig_size, and orig_crc are completely different. But then there are 10 bytes that are equal: 0x7F07454C4602011E1501. These bytes include the ELF magic ELF, which is not at the beginning but does not get disfigured like the PE magic MZ to M8Z. Right now, I am not sure if this is a consistent behavior across all ELF files or just for ELF x64 files.

Again, we can write a YARA rule for this:

rule aplib_compressed_elf_executable {
     meta:
         author = "Thomas Barabosch"
         version = "20200109"
         description = "Detects aPLib compressed ELF executables. Note that there may be a aPLib header starting 24 bytes BEFORE the match!"
     strings:
         $aplib_compressed_elf = { 7F 07 45 4C 46 02 01 1E }
     condition:
         $aplib_compressed_elf
  }

The YARA rules that I’ve presented here leave room for improvement. For example, we can check for cases where we have an aPLib header followed by a compressed PE executable, and so on. Be creative and let me know what you’ve found out!

aPLib decompression

Finally, we’ve learned so much about aPLib compression, how to spot it with our bare eyes and detect it with YARA. But there is one final piece missing: we need to talk about aPLib decompression. The following sections show you how to achieve aPLib decompression with three different tools.

aPLib decompression with apack

Before looking at more complex scenarios, we can always resort to the tools that come with aPLib. The library comes with an example tool called appack. The source of this tool is stored under examples/appack.c and there are several make files for various platforms. appack offers two commands c and d:

appack, aPLib compression library example
 Copyright 1998-2014 Joergen Ibsen (www.ibsensoftware.com)
 Syntax:
 `Compress    :  appack c <file> <packed_file> `
 `Decompress  :  appack d <packed_file> <depacked_file>`

For instance, we can decompress an aPLib compressed blob with the d command as in the following snippet illustrated:

> appack d bin_ls.bin bin_ls
 appack, aPLib compression library example
 Copyright 1998-2014 Joergen Ibsen (www.ibsensoftware.com)
 Decompressed 66101 -> 151352 bytes in 0.01 seconds

That’s it, pretty simple. But this is not suitable for more complex scenarios, e.g. automation. Here, we have two options. First, we can use the aPLib library itself and write C programs. Second, we can automate aPLib decompression using Python.

aPLib decompression with malduck

Lately, I utilize Malduck a lot. So, let’s see how we can decompress an aPLib compressed blob with it. We can decompress these files with the following script based on Malduck:

import malduck
import sys
def main(argv):
    `if len(argv) != 2:`
`        print('Usage: aplib.py PATH_TO_APLIB_COMPRESSED_BUFFER')`
   ` `
    `with open(argv[1], 'rb') as f:     `
        `data = f.read()     `
        `try:         `
            `res = malduck.aplib(data)`
   `         if res:`
`                with open(argv[1] + '_aplib_decompressed', 'wb') as g:`
`                    g.write(res)`
`            else:`
   `             print(f'Malduck did not decompress the buffer.')`
   `     except Exception as e:`
`            print(f'Could not aplib decompress: {e}')`
 if <strong>name</strong> == '<strong>main</strong>':
     main(sys.argv)

The function malduck.aplib may take a flag called headerless. This flag forces headerless compression and does not check for the AP32 magic. It defaults to True.

Even though this script seems to be trivial, it is a perfect skeleton for more complex tasks that resolve around aPLib compression. For instance, if you’ve to write a script for extracting the malware configuration of a specific family, which happens to use aPLib as part of the way how it stores its configuration.

aPLib decompression with aplib-ripper

Another great tool is aplib-ripper by herrcore. It rips one or several aPLib compressed PE executables from a blob. It searches for the string M8Z, forces a headerless decompression, and finally verifies and trims the output with pefile.

The malware analyst's guide to zlib compression

Sat, 02 Jan 2021 17:50:54 +0000

Reviewed July 2026: This post is kept for the detection and analysis workflow. Version-specific tool output may have changed since publication.

Malware often utilizes data compression like zlib or aPLib. There are several reasons for this behavior: first, it saves space and makes binaries smaller and network transfers faster. Second, it adds another layer of obfuscation as the malware analyst needs to detect the compression algorithm first. One of the widely adopted data compression libraries in malware is zlib. For instance, malware families like GhostRat utilize zlib compression.

RFC1950 defines the ZLIB Compressed Data Format. zlib is an open-source platform-independent compression library. At the time of writing, the current version was 1.2.11. It uses the deflate compression algorithm. Since the Deflate algorithm is out of the scope of this article, I can really recommend reading the Wikipedia article about this compression algorithm.

Detect if a binary statically links against zlib

Spotting zlib in malicious code is often times very easy. Since many malware authors do not remove strings, the name of zlib‘s author (Marc Adler) and several error messages can be found in the binary:

“incorrect header check”
“too many length or distance symbols”

Detect aPLib compression with your bare eyes

RFC1950 states that a zlib stream has the following structure:

  0   1          
+---+---+          
|CMF|FLG|   (more-->)          
+---+---+

where CMF stands for Compression Method and flags and FLG stands for FLaGs. These two fields can have the following values:

0x7801, which stands for no compression or low compression
0x789C, which stands for default compression
0x78DA, which stand for best compression

So, if you spot these values at the beginning of a data stream, then chances are high that you are dealing with zlib compression.

For instance, the following screenshot shows a zlib compressed PE file using best compression (level 9). Note the marked first two bytes 0x78DA.

In the following sections, I’ll review several ways how zlib compressed blobs can be uncompressed. First, I’ll show how to decompress them on the command line. Next, I’ll show you how to do zlib decompression with Python.

zlib decompression on the command line

OpenSSL can decompress zlib compressed blobs. One of its Cipher commands is zlib. Using the flag -d allows us to decompress blobs. The following example decompresses a zlib compressed PE file with OpenSSL.

> file compressed.bin   
 compressed.bin: zlib compressed data
> hexdump compressed.bin | head -n 5
 0000000 da78 bdec 7809 c55b 30d5 f73c b16a d96c
 0000010 ec96 8e48 d89c 9289 c4d8 9b21 2ced 9024
 0000020 cb50 6c96 c889 9096 38e4 5366 5964 45b6
 0000030 4964 c968 5bc2 c04a d684 4375 8503 94be
 0000040 96d2 2db7 b42d 05b4 d65a 38b2 2584 2dd0
> openssl zlib -d < compressed.bin > decompressed.bin 
> file decompressed.bin 
 decompressed.bin: PE32+ executable (console) x86-64, for MS Windows
> hexdump decompressed.bin | head -n 5
 0000000 5a4d 0090 0003 0000 0004 0000 ffff 0000
 0000010 00b8 0000 0000 0000 0040 0000 0000 0000
 0000020 0000 0000 0000 0000 0000 0000 0000 0000
 0000030 0000 0000 0000 0000 0000 0000 0080 0000
 0000040 1f0e 0eba b400 cd09 b821 4c01 21cd 6854

Using openssl zlib < INPUT > OUTPUT on the other hand allows us to compress binary files on the command line.

zlib decompression with Python

First, there is an entire zlib module in the Python standard lib. That’s wonderful news since we can deal with all zlib compression/decompression issues in Python.

The following code snippet shows how to decompress in case a zlib header is present.

# https://docs.python.org/2/library/zlib.html
# if blob has a zlib header then the BLOB can be decompressed simply by calling
import zlib
zlib.decompress(BLOB)

However, a common obfuscation technique in malware is not using a zlib header. The following code snippet shows how to deal with such blobs.

# Source: http://stackoverflow.com/questions/561607/identifying-algorithms-in-binaries
# "From my experience, most of the times the files are compressed using plain old Deflate.
# You can try using zlib to open them, starting from different offset to compensate for custom headers.
# Problem is, zlib itself adds its own header. In python (and I guess other implementations has that feature as well),
# you can pass to zlib.decompress -15 as the history buffer size (i.e. zlib.decompress(data,-15)),
# which cause it to decompress raw deflated data, without zlib's headers."
import zlib
zlib.decompress(BLOB,-15)

Never upload ransomware samples to the Internet

Mon, 28 Dec 2020 22:51:09 +0000

Ransomware is our contemporary plague. It is a thriving business that attracts more and more cybercriminals every month. New ransomware gangs sprout like mushrooms. These self-proclaimed “security teams” test the security of many small to large enterprises. But their unsolicited penetration tests are not that cheap. What they leave behind is pure mayhem and a huge bill for the victims. Furthermore, some attacks are really disgusting since ransomware gangs have targeted non-profit organizations, schools, and even hospitals on various occasions.

There are hundreds of articles on the Internet about ransomware. For instance, the No More Ransom project educates on ransomware and offers help for victims. There are technical approaches to stop ransomware. Of course, the cyber security industry offers many products to protect against or mitigate ransomware. There are also community approaches like Raccine that help to stop ransomware.

But once ransomware has been deployed on your network and you are in a ransomware incident, the headless chicken mode is very common. Unfortunately, there is one golden rule that I often see getting broken due to headless chicken mode:

NEVER EVER upload ransomware samples to the Internet!

Some random incident responder

Even though I thought that this would be common knowledge, I’ve been proven wrong many times. Therefore, this is my take at explaining what information a ransomware sample contains, why you should never upload them to the Internet, and what actually happens if you upload them after all.

Audience: This is definitively not an article for the seasoned Cyber Threat Intelligence analyst or the alike. This is an article dedicated to the ones in many smaller to medium businesses, schools, hospitals, and so on that do not have a dedicated security team: the non-security IT staff including system administrators that are typically the firsts to encounter the mess ransomware gangs leave behind. But also entry-level cyber security professionals can benefit from reading this article and understand how analysts hunt for ransomware samples.

What kind of information does a ransomware sample contain?

Ransomware is only the last step of a network intrusion. It may have started with a spear-phishing mail, later on, some undetected lateral movement, and subsequently the take over of your Windows Domain Controller. At this point in time, the attacker may deploy the ransomware on the network on a lonely Friday night.

These ransomware samples are often compiled for the victim at hand. They are therefore unique. Hence, they contain a lot of information related to the victim that should not be made public. This information includes:

a ransom note with
- the name of the victim
- names of network shares
- names of computers in the network
- names of employees (as part of network share paths)
- names of clients
- type of stolen data (e.g. accounting data, executive data, …)
- links to screenshots as proof (e.g. data listings, bank account balances, …)
meta-information
- the timestamp of the ransomware sample that can be used to estimate the date of the attack

The following ransom note that I’ve extracted from a ransomware sample uploaded to the Internet illustrates my point:

Example ransom note containing a lot of information about the victim.

Needless to say that this information should not turn up on the Internet. I know that some will argue that this information will be public soon anyway if the victim does not pay the ransom. Because modern ransomware gangs use the double extortion tactic. In a nutshell, before deploying the ransomware, these gangs steal (sometimes) terabytes of data from a network and threaten to publish this information on the Darknet or sell/auction it off.

By the way, paying the ransom is something that is never recommended. Above all, because this proves to cybercriminals that this is an effective way of making money. Furthermore, this may have severe consequences for a business, if it pays cybercriminals residing somewhere in an embargoed region.

Why shouldn’t I upload ransomware samples to the Internet?

As you’ve seen, there is a lot of information related to the victim that a ransomware sample contains. Once IT staff is confronted with a ransomware incident, they may start their own investigation, trying to find the root of all evil. One of these steps is typically uploading many of the suspicious files found on the network to online services like VirusTotal. Consequently, these samples are public on the Internet.

Unfortunately, this is a common mistake that IT staff unaware of cyber security subtleties commits. What do you gain by uploading ransomware samples? You probably know already that the sample at hand is malware because it encrypted most of your network. Often the classification of the malware, if that really matters at this particular moment, is often proudly presented by the malware itself. Either as a file extension of all the encrypted files or in the ransom note. Therefore, you are not gaining anything, but possibly losing a lot.

Services like VirusTotal are very good to check if a file is malicious and you suspect that it is commodity malware. Therefore, the first step is never to upload a file but rather check its file hash, e.g. sha256. Somebody else usually has uploaded the sample for us anyway. There are great tools like malwoverview that help you with this task.

If a hash does not yield a result then there are several explications. First, the sample is too fresh that somebody has uploaded it yet, check back a couple of minutes later. Second, the threat actor uses hash busting and changes the hash of each sample. Third, this sample is unique because it was utilized in a targeted attack.

The third point is the point that applies to ransomware. The sample is unique. Ransomware threat actors compile their samples typically for each victim just before the deployment. Even though this is not a nation-state actor that attacked your network, you should treat the sample as if it were from one due to the information leakage that would occur on upload.

Even though not uploading ransomware samples to the Internet won’t fix the core problem you may have, i.e. an encrypted network, this will likely make your (at this point in time miserable) life a little bit brighter.

Because you have much more time to focus on the actual incident and you do not have to deal with a media disaster right from the beginning! Perhaps this gives your press relations officer some time to prepare a proper statement.

Furthermore, note that this is a way to identify ransomware victims that paid the ransom and never showed up on any ransomware portal. The proof that they fall victim and paid will be out there forever. Mind the possible consequences I’ve stated above.

What happens if I upload a ransomware sample to the Internet?

There are many analysts out there that hunt for these samples for several reasons. One of them is not that noble but very common: public discussion of who got ransomwared by whom. This is then picked up by the press and it is something that you do not need when already in a ransomware incident, possibly in headless chicken mode anyway.

Let me illustrate by the example of VirusTotal what happens. The following applies to similar services on the Internet. I choose VirusTotal because it probably the most common choice of IT staff to upload malicious samples. It is not that I am blaming anything on this very useful service. Actually, VirusTotal tells you this in their Terms of Service, their Privacy Policy, and again right about the time you click on “Submit”:

By submitting data below, you are agreeing to our Terms of Service and Privacy Policy, and to the sharing of your Sample submission with the security community. Please do not submit any personal information; VirusTotal is not responsible for the contents of your submission.

VirusTotal

So, you’ve been warned a lot!

But you may ask: how do analysts find my sample in the endless stream of files uploaded to VirusTotal? This is where LiveHunt comes into play. This is a service that is offered to customers and researchers to hook into the never-ending stream of files uploaded. Each file is checked against custom signatures (YARA rules). Furthermore, these samples are shared with AV companies who will likely have other ways to find the needle in the haystack.

If you know exactly what you are looking then it is quite easy to find the needle in the haystack. This means once you have analyzed one sample of a certain ransomware family, written a YARA rule for it, then you will likely detect it in the future again. Actually, you do not have to write many rules on your own because there are plenty on GitHub. For instance, the following is a YARA rule for the ransomware family Ryuk:

rule Ransom_Ryuk_sept2020 {                 
   meta:       
      description = "Detecting latest Ryuk samples"         
      author = "McAfe ATR"          
      date = "2020-10-13"           
      malware_type = "ransomware"       
      malware_family = "Ransom:W32/Ryuk"           
      actor_type = "Cybercrime"          
      actor_group = "Unknown"           
      hash1 = "cfdc2cb47ef3d2396307c487fc3c9fe55b3802b2e570bee9aea4ab1e4ed2ec28"       
                
   strings:           
      $x1 = "\" /TR \"C:\\Windows\\System32\\cmd.exe /c for /l %x in (1,1,50) do start wordpad.exe /p " fullword ascii         
      $x2 = "cmd.exe /c \"bcdedit /set {default} recoveryenabled No & bcdedit /set {default}\"" fullword ascii          
      $x3 = "cmd.exe /c \"bootstatuspolicy ignoreallfailures\"" fullword ascii        
      $x4 = "cmd.exe /c \"vssadmin.exe Delete Shadows /all /quiet\"" fullword ascii           
      $x5 = "C:\\Windows\\System32\\cmd.exe" fullword ascii            
      $x6 = "cmd.exe /c \"WMIC.exe shadowcopy delete\"" fullword ascii            
      $x7 = "/C REG ADD \"HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\" /v \"EV\" /t REG_SZ /d \"" fullword wide          
      $x8 = "W/C REG DELETE \"HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\" /v \"EV\" /f" fullword wide             
      $x9 = "\\System32\\cmd.exe" fullword wide            
      $s10 = "Ncsrss.exe" fullword wide               
      $s11 = "lsaas.exe" fullword wide              
      $s12 = "lan.exe" fullword wide              
      $s13 = "$WGetCurrentProcess" fullword ascii            
      $s14 = "\\Documents and Settings\\Default User\\sys" fullword wide            
      $s15 = "Ws2_32.dll" fullword ascii            
      $s16 = " explorer.exe" fullword wide            
      $s17 = "e\\Documents and Settings\\Default User\\" fullword wide             
      $s18 = "\\users\\Public\\" fullword ascii             
      $s19 = "\\users\\Public\\sys" fullword wide              
      $s20 = "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\" fullword ascii       
        
      $seq0 = { 2b c7 50 e8 30 d3 ff ff ff b6 8c }       
      $seq1 = { d1 e0 8b 4d fc 8b 14 01 89 95 34 ff ff ff c7 45 }            
      $seq2 = { d1 e0 8b 4d fc 8b 14 01 89 95 34 ff ff ff c7 45 }       
                
   condition:            
      ( uint16(0) == 0x5a4d and              
      filesize < 400KB and                
      ( 1 of ($x*) and 5 of them ) and                 
      all of ($seq*)) or ( all of them )       
}

This rule comprises several strings and a condition that is checked against each file. The condition matches, roughly speaking, Windows binaries that are less than 400 kilobytes in size and comprise a certain number of the aforementioned strings.

Let’s say you uploaded a ransomware sample to VirusTotal, which belongs to one of the heavily tracked ransomware families then there are likely several YARA rules going off, and researchers notified. Notifications are either seen in the VirusTotal WebGUI or via email notification as shown in the following screenshot.

Sample notification received for a ransomware sample.

Now even further meta information is attached to the ransomware sample. For instance, the country from where the sample was uploaded, which might be used to track down the exact location of the victim if it is a branch of an enterprise operating in many countries.

And finally, at some point, you will contract an incident responder because it is very likely that your in-house capabilities won’t be enough. If you tell them that you’ve just uploaded the sample to some online service, chances are that they will not be amused. I’ve never come along an incident responder that was happy when their client uploaded a ransomware sample to the Internet…

Linux from Scratch - Is it worth it?

Fri, 25 Dec 2020 16:30:11 +0000

Reviewed July 2026: This post is kept as a historical reflection on Linux from Scratch 8.0. Version-specific links and package versions may no longer match the current LFS book.

One thing on my ever-growing ToDo list was to build my own Linux system since I stumbled upon Linux from Scratch (LFS) a couple of years ago. LFS is an online book that guides you through the whole process of building your own minimal Linux system. It consists of several phases: initially, you create partitions for your new system and download all the packages you need to build it. Then, you add an initial user LFS and set up a temporary system with a clean toolchain (assembler, compiler, linker) as well as other system tools. Next, you chroot into your temporary system, create essential files and folders, mount virtual filesystems like /dev and /sys and start to compile essential packages with your new toolchain. Finally, you install boot scripts, compile the Linux kernel, install Grub, and reboot. And wait, don’t forget to pray before booting into your system!

The book’s chapters are well-structured. They present you command lines commands to execute in order to, for instance, to build one piece of the puzzle and reasons why this piece is required, e.g. see the chapter on Bzip2. Even though the LFS book suggests that the system you build is fully usable and could be used as the primary system, it is more an educational project. For instance, do not expect to end up with a comfortable package manager like apt-get. Hence, many LFSers are likely to build their system in a virtual machine. One clear advantage is that you can create snapshots during the build process, which is assumed to take place in one pass without turning off your machine. Otherwise, you have to set up your chroot again.

Based on a such minimal system, further guides can be followed to get something more usable. These guides include Beyond Linux From Scratch, which also introduces security measures to the system, and Cross Linux From Scratch, which teaches how to cross-compile and how to build multilib environments.

I followed Linux from Scratch 8.0, which was the stable version I used at the time. It built a Linux system based on the Linux Kernel in version 4.9.9. There are three major points, making LFS a great project for a couple of evenings, which I discuss in the following. Finally, I wrap up my lines of thoughts in a quick conclusion.

What is really needed to end up with a bash shell? Which package depends on which one? What are all these libraries in my libs directories good for? There are many questions you could pose here. LFS makes you realize what it takes to build a minimal Linux system. For instance, it made me realize what forms binutils, coreutils and util-linux. Tools that I use on a daily basis, I took them for granted but never knew where they came from.

Learning by Doing

LFS is Learning by doing, no beating around the bush here. You build a Linux system from scratch with your bare hands! After theory comes implementation. The stuff you learn here should be applicable to a wide range of Linux-related problems. Be it building your own cross-compiling toolchain as you actually do in LFS, be it building your custom Linux system for an embedded platform.

Furthermore, for those that would like to get into OS development, Linux from Scratch allows them to review certain key concepts like the toolchain of linker, compiler, assembler, which are critical to OS development. Before diving into OS development, I would certainly recommend going through LFS to see how to glue components together to an OS.

However, you won’t code anything. For instance, the LFS guys provide you with a set of init scripts so that you don’t need to write custom ones. They serve as a fully-working template: study them and extend them, if needed.
But IMHO it would be too much to extend these scripts in a first LFS iteration. A rough understanding of the boot process is sufficient.

Take your time – It is well spent and worth it!

Take your time! I repeat slowly: take your time! I guess many just rush through the chapters, blindly executing commands, and end up with a working Linux system, without ever having understood what has happened. If you do this, it just boils to many ./configure && make && make install calls. And actually there are tools to automate the whole LFS process.

Linux from Scratch should be rather seen as a marathon than as a quick sprint. There will be so many questions popping up in your mind. Try to follow them, search for answers on Google or Wikipedia while your computer is heating your room. Most of the time, I started by reading the project’s Wikipedia page and in case there were still open questions I consulted the project’s website. This made me read up on the project’s history, the people, and the organizations behind and it enabled me to see connections between various projects. Then, I started to poke around in the project’s folder structure and opened some source files. After compilation and installation, I checked the files produced and the locations where they were put.

Doing this, for example, made me realize what kind of a monster gcc really is. … It made me think about the pros and cons of gcc and why llvm is a brilliant compiler. So I continued to read up more on the pros and cons of clang/llvm and gcc. I knew that llvm is the default compiler on macOS, where I already enjoy it. However, the fact that FreeBSD and Sony’s PS4 system software also use clang/llvm was new to me. Actually, there is a project that provides patches for the Linux kernel in order to make it compilable with clang. As you can see, you can start with one thing and end up on the PS4. Nevertheless, it is very educational and many new ideas will come to your mind.

Final thoughts on Linux from Scratch

First, of it all, it is a nice feeling to boot into your own Linux system, built with your bare hands. You end up with run level 3, a simple bash shell, nothing fancy at all. You see the cursor blinking and think: “Puh, I did not mess anything up”, since there are so many pitfalls. Then, you relax and toy around with your system. Totally worth it!

Of course, I did register my Linux from Scratch system at the lfscounter:

You have successfully registered!
ID: 26656
Name: Thomas Barabosch
First LFS Version: 8.0

Even though 26656 seems to be a huge number, it isn’t if you take into account that LFS will turn 20 next year. On the other side, not everybody registers his system.

There is so much future work still left. As mentioned earlier, no package manager is installed. Actually, the current strategy is It is All in My Head!, which only works for a very exclusive group of Linux users:

Yes, this is a package management technique. Some folks do not find the need for a package manager because they know the packages intimately and know what files are installed by each package. Some users also do not need any package management because they plan on rebuilding the entire system when a package is changed.

In the end, I invested several evenings to build the whole system, even though my initial SBU was less than five minutes. In retrospect, time was invested well. Can I now compile my custom Linux distribution and ditch my Ubuntu installation? Probably not, but it is a start and some may dive deeper into this topic because of Linux from Scratch. For me, the next thing to do is Beyond Linux From Scratch and to have a look at how exactly security features like PAM are incorporated in a Linux system.

How to patch a Windows API in x64dbg

Thu, 24 Dec 2020 12:00:00 +0000

Reviewed July 2026: This post is kept as a historical debugging note. The x64dbg and Python plugin APIs may have changed since publication.

Some months ago, I analyzed a banking Trojan that employed a chain of injections. First, it hollowed an instance of svchost.exe. From there, it injected its code into several processes (especially browsers). My goal was to analyze the network protocol. Unfortunately, all processes could communicate with the CC and there was a mutual exclusion scheme that ensured only one network communicator at a time. This resulted in my process never contacting the CC and in me not seeing the network protocol.

My quick hack was to prevent others instances to communicate via the network by preventing further code injections. The malware at hand utilized ZwOpenProcess during its code injections. The solution: patch a Windows API in x64dbg to always return zero yielded no more injections. And finally, I was able to tamper with the network protocol.

Most of the time I utilize x64dbg, an open source debugger. Since a couple of months python bindings exist. They work fine, though there is no documentation. The following gist does the trick: patching ZwOpenProcess to always return zero. This should yield no more code injections in many malware families. Furthermore, you can use it as a blueprint for patching other APIs in x64dbg.

from x64dbgpy.pluginsdk import *       
                         
def patchZwOpenProcess():       
    # This function patches the function ZwOpenProcess in such way that the XXX fails to open and infect more processes       
    # The good thing about that is that there won't be any concurrency issues and you can be sure that the networking       
    # will be done in the current process.       
                
    # patches mov eax, 0; jmp TO_RETURN (should be +3)       
    PATCH = "\xB8" + "\x00" * 4 + "\xEB\x03" + "\x90" * 3       
    addrZwOpenProcess = RemoteGetProcAddress('ntdll', 'ZwOpenProcess')       
    memory.Write(addrZwOpenProcess, PATCH)       
                
def main():       
    patchZwOpenProcess()       
                
main()

The gist just assembles some shellcode (mov eax, 0; jmp TO_RETURN) to force the API to return zero, resolves the target API with RemoteGetProcAddress and overwrites the original code of the api with memory.Write. As I said, there is no documentation of x64dbgpy. You can refer to this folder of x64dbgpy’s repo.