{ "id": "60e6f7fe-b19e-4d83-8a85-87b850cd6bf0", "created_at": "2026-04-06T00:12:51.580674Z", "updated_at": "2026-04-10T03:24:30.039165Z", "deleted_at": null, "sha1_hash": "cb0f1bc3dc9f37a7d2ff04e6c306fd5e28d1de58", "title": "Windows API Hashing in Malware | Red Team Notes", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 86830, "plain_text": "Windows API Hashing in Malware | Red Team Notes\r\nPublished: 2023-03-05 ยท Archived: 2026-04-05 19:19:30 UTC\r\n1. offensive security\r\n2. Defense Evasion\r\nWindows API Hashing in Malware\r\nEvasion\r\nThe purpose of this lab is to get a bit more familiar with API Hashing - a technique employed by malware\r\ndevelopers, that makes malware analysis a bit more difficult by hiding suspicious imported Windows APIs from\r\nthe Import Address Table of the Portable Executable.\r\nAPI hashing example described in this lab is contrived and hash collisions ar possible.\r\nProblem (for Malware Developers)\r\nIf 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\r\nsee that the binary loads Ws2_32.dll , it's safe to assume that it contains some networking capabilities, or if we\r\nsee a function RegCreateKeyEx being imported, we know that the binary has ability to modify the registry, etc.\r\nSolution (for Malware Developers)\r\nMalware authors want to make initial PE analysis/triage harder by simply looking at the IAT, and for this reason\r\nthey may use API hashing to hide suspicious API calls from the IAT. This way, when an analyst runs the malicious\r\nbinary through the strings utility or opens it in some PE parser, the Windows APIs that malware developer did\r\nnot want the analyst to know without deeper analysis, will be hidden.\r\nAssume we have written some malware called api-hashing.exe that uses CreateThread :\r\nIf we compile the above code and inspect it via a PE parser, we see that there are 28 imported functions from\r\nkernel32 library and CreateThread is one of them:\r\nFor some reason, we decide that we do not want malware analysts to know that our malware will be calling\r\nCreateThread just by looking at the binary's IAT/running strings against the binary. To achieve this, we can\r\nemploy the API hashing technique and resolve CreateThread function address at runtime. By doing this, we can\r\nhttps://www.ired.team/offensive-security/defense-evasion/windows-api-hashing-in-malware\r\nPage 1 of 6\n\nmake the CreateThread disappear from the PE's IAT, and this is exactly the purpose of this lab - to see how this\r\ntechique works in real life.\r\nIn this lab we're going to write:\r\n1. A simple powershell script that will calculate a hash for a given function name. For example, feeding a\r\nstring CreateThread to the script will spit out its representation as a hash value, which in our lab, as we\r\nwill see later, will be 0x00544e304\r\n2. 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\r\nCreateThread lives), calculating their hashes (using our hashing algoritm) and comparing them to our\r\nhash 0x00544e304 (for CreateThread ). In our case, the program will spit out a virtual address\r\n00007FF89DAFB5A0 as will be seen later.\r\nVisually, the process of what we are going to do looks something like this:\r\nAPI hashing is simply an arbitrary (that we can make up on our own) function / algorithm, that calculates a\r\nhash value for a given text string.\r\nIn our case, we defined the hashing algorithm to work like this:\r\n1. Take the function name to be hashed (i.e CreateThread )\r\n2. Convert the string to a char array\r\n3. Set a variable $hash to any initial value. In our case, we chose 0x35 - no particular reason - as\r\nmentioned earlier, hash calculation can be any arbitrary algorithm of your choice - as long as we can\r\nreliably create hashes without collisions, meaning that no two different API calls will result in the same\r\nhash value.\r\n4. Iterate through each character and perform the following arithmetics - hash calculation\r\n1. Convert character to a hex representation\r\n2. Perform the following arithmetics $hash += $hash * 0xab10f29f + $c -band 0xffffff , where:\r\n1. 0xab10f29f is simply another random value of our choice\r\n2. $c is a hex representation of the character from the function we're hashing\r\n3. -band 0xffffff is for masking off the high order bits of the hash value\r\n5. Spit out the hash representation for the string CreateThread\r\nOur hashing function has not been tested for hash collisions and is only meant to demonstrate the idea behind it. In\r\nfact, YoavLevi informed me that this function indeed causes hash collisions for at least these two APIs:\r\nGetStdHandle 0x006426be5 CloseHandle 0x006426be5\r\nhttps://www.ired.team/offensive-security/defense-evasion/windows-api-hashing-in-malware\r\nPage 2 of 6\n\n$APIsToHash = @(\"CreateThread\")\r\n$APIsToHash | % {\r\n $api = $_\r\n \r\n $hash = 0x35\r\n [int]$i = 0\r\n $api.ToCharArray() | % {\r\n $l = $_\r\n $c = [int64]$l\r\n $c = '0x{0:x}' -f $c\r\n $hash += $hash * 0xab10f29f + $c -band 0xffffff\r\n $hashHex = '0x{0:x}' -f $hash\r\n $i++\r\n write-host \"Iteration $i : $l : $c : $hashHex\"\r\n }\r\n write-host \"$api`t $('0x00{0:x}' -f $hash)\"\r\n}\r\nIf we run the hashing function against the string CreateThread , we get its hash - 0x00544e304 :\r\nWe are now ready to move on to the C program that will resolve CreateThread function address by parsing out\r\nthe Kernel32 module's Export Address Table and tell us where CreateThread function is stored in our\r\nmalicious process's memory, based on the hash we've just calculated - 0x00544e304 .\r\nResolving Address by Hash\r\nOur C program will have 2 functions:\r\ngetHashFromString - a function that calculates a hash for a given string. This is an identital function (related to\r\nthe hash calculation) to the one that we wrote earlier for hashing our function name CreateThread in Powershell.\r\nOn the left is the getHashFromString in our C program and on the right is the powershell version of the hash\r\ncalculation algorithm:\r\ngetFunctionAddressByHash - this is the function that will take a hash value ( 0x00544e304 in our case for\r\nCreateThread ) as an argument and return function's, that maps back to that hash, virtual address -\r\n00007FF89DAFB5A0 in our case.\r\nThis function at a high level works like this:\r\n1. Get a base address of the library where our function of interest ( CreateThread ) resides, which is -\r\nkernel32.dll in our case\r\n2. Locates kernel32 Export Address Table\r\nhttps://www.ired.team/offensive-security/defense-evasion/windows-api-hashing-in-malware\r\nPage 3 of 6\n\n3. Iterates through each exported function name by the kernel32 module\r\n4. For each exported function name, calculates its hash value using the getHashFromString\r\n5. If calculated hash equals 0x00544e304 (CreateThread) , calculate function's virtual address\r\n6. At this point, we could typedef the CreateThread function prototype, point it to the resolved address in\r\nstep 5 and use it for creating new threads, but this time without CreateThread being shown in our\r\nmalware PE's Import Address Table!\r\nBelow is our aforementioned C program that resolves CreateThread function address by the hash\r\n( 0x00544e304 ):\r\n#include \u003ciostream\u003e\r\n#include \u003cWindows.h\u003e\r\nDWORD getHashFromString(char *string)\r\n{\r\nsize_t stringLength = strnlen_s(string, 50);\r\nDWORD hash = 0x35;\r\nfor (size_t i = 0; i \u003c stringLength; i++)\r\n{\r\nhash += (hash * 0xab10f29f + string[i]) \u0026 0xffffff;\r\n}\r\n// printf(\"%s: 0x00%x\\n\", string, hash);\r\nreturn hash;\r\n}\r\nPDWORD getFunctionAddressByHash(char *library, DWORD hash)\r\n{\r\nPDWORD functionAddress = (PDWORD)0;\r\n// Get base address of the module in which our exported function of interest resides (kernel32 in the c\r\nHMODULE libraryBase = LoadLibraryA(library);\r\nPIMAGE_DOS_HEADER dosHeader = (PIMAGE_DOS_HEADER)libraryBase;\r\nPIMAGE_NT_HEADERS imageNTHeaders = (PIMAGE_NT_HEADERS)((DWORD_PTR)libraryBase + dosHeader-\u003ee_lfanew);\r\nDWORD_PTR exportDirectoryRVA = imageNTHeaders-\u003eOptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPOR\r\nPIMAGE_EXPORT_DIRECTORY imageExportDirectory = (PIMAGE_EXPORT_DIRECTORY)((DWORD_PTR)libraryBase + expor\r\n// Get RVAs to exported function related information\r\nPDWORD addresOfFunctionsRVA = (PDWORD)((DWORD_PTR)libraryBase + imageExportDirectory-\u003eAddressOfFunction\r\nPDWORD addressOfNamesRVA = (PDWORD)((DWORD_PTR)libraryBase + imageExportDirectory-\u003eAddressOfNames);\r\nhttps://www.ired.team/offensive-security/defense-evasion/windows-api-hashing-in-malware\r\nPage 4 of 6\n\nPWORD addressOfNameOrdinalsRVA = (PWORD)((DWORD_PTR)libraryBase + imageExportDirectory-\u003eAddressOfNameOr\r\n// Iterate through exported functions, calculate their hashes and check if any of them match our hash o\r\n// If yes, get its virtual memory address (this is where CreateThread function resides in memory of our\r\nfor (DWORD i = 0; i \u003c imageExportDirectory-\u003eNumberOfFunctions; i++)\r\n{\r\nDWORD functionNameRVA = addressOfNamesRVA[i];\r\nDWORD_PTR functionNameVA = (DWORD_PTR)libraryBase + functionNameRVA;\r\nchar* functionName = (char*)functionNameVA;\r\nDWORD_PTR functionAddressRVA = 0;\r\n// Calculate hash for this exported function\r\nDWORD functionNameHash = getHashFromString(functionName);\r\n// If hash for CreateThread is found, resolve the function address\r\nif (functionNameHash == hash)\r\n{\r\nfunctionAddressRVA = addresOfFunctionsRVA[addressOfNameOrdinalsRVA[i]];\r\nfunctionAddress = (PDWORD)((DWORD_PTR)libraryBase + functionAddressRVA);\r\nprintf(\"%s : 0x%x : %p\\n\", functionName, functionNameHash, functionAddress);\r\nreturn functionAddress;\r\n}\r\n}\r\n}\r\n// Define CreateThread function prototype\r\nusing customCreateThread = HANDLE(NTAPI*)(\r\nLPSECURITY_ATTRIBUTES lpThreadAttributes,\r\nSIZE_T dwStackSize,\r\nLPTHREAD_START_ROUTINE lpStartAddress,\r\n__drv_aliasesMem LPVOID lpParameter,\r\nDWORD dwCreationFlags,\r\nLPDWORD lpThreadId\r\n);\r\nint main()\r\n{\r\n// Resolve CreateThread address by hash\r\nPDWORD functionAddress = getFunctionAddressByHash((char *)\"kernel32\", 0x00544e304);\r\n// Point CreateThread function pointer to the CreateThread virtual address resolved by its hash\r\ncustomCreateThread CreateThread = (customCreateThread)functionAddress;\r\nDWORD tid = 0;\r\n// Call CreateThread\r\nHANDLE th = CreateThread(NULL, NULL, NULL, NULL, NULL, \u0026tid);\r\nhttps://www.ired.team/offensive-security/defense-evasion/windows-api-hashing-in-malware\r\nPage 5 of 6\n\nreturn 1;\r\n}\r\nIf we compile and run the code, we will see the following:\r\n...where from left to right:\r\n1. CreateThread - function name that was resolved for the given hash 0x00544e304\r\n2. 0x00544e304 - hash that was used to resolve the said CreateThread function name\r\n3. 00007FF89DAFB5A0 - CreateThread virtual memory address inside our api-hashing.exe process\r\nBelow image confirms that 00007FF89DAFB5A0 is indeed pointing to the CreateThread inside api-hashing.exe :\r\n...and more importantly, its IAT is now free from CreateThread :\r\nTesting if CreateThread Works\r\nBelow shows that we can now successfully call CreateThread which was resolved at run time by hash\r\n0x00544e304 - this is confirmed by the obtained handle 0x84 to the newly created thread:\r\nBelow also shows the thread ID that was created during our CreateThread invokation:\r\nThis site uses cookies to deliver its service and to analyze traffic. By browsing this site, you accept the privacy\r\npolicy.\r\nSource: https://www.ired.team/offensive-security/defense-evasion/windows-api-hashing-in-malware\r\nhttps://www.ired.team/offensive-security/defense-evasion/windows-api-hashing-in-malware\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.ired.team/offensive-security/defense-evasion/windows-api-hashing-in-malware" ], "report_names": [ "windows-api-hashing-in-malware" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434371, "ts_updated_at": 1775791470, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/cb0f1bc3dc9f37a7d2ff04e6c306fd5e28d1de58.pdf", "text": "https://archive.orkl.eu/cb0f1bc3dc9f37a7d2ff04e6c306fd5e28d1de58.txt", "img": "https://archive.orkl.eu/cb0f1bc3dc9f37a7d2ff04e6c306fd5e28d1de58.jpg" } }