Intro
There’s a lot of Windows APIs available to developers, recently we saw a post by Marcus Hutchins on LinkedIn around the malicious use of section related APIs in Windows (link to post), we noted replies from those previously unaware of these techniques asking how they could have discovered these APIs themselves, with responses indicating reverse engineering of Windows components was the method of discovery.
We’re going to explore other methods of technique discovery that do not require reverse engineering and when reverse engineering of components can be helpful.
Documented APIs
Windows documents a lot of their APIs, you can find the documentation hosted on their website (e.g. CreateFileA documentation), the downloadable SDKs may also include useful comments.
If you read enough of the docs you may notice certain patterns, for example consider the documentation for CreateFileA, GetFileAttributesA and CreateFileFromAppW, what do they have in common?
You may have noticed that Microsoft tends to follow a naming convention, you’ll note in the APIs above they all use lpFileName as the parameter name to describe the input parameter associated with “The name of the file or device”, “The name of the file or directory” or something similar, all associated with the name of something commonly on disk or accessible via a path.
How does this relate to the initial post on discovering section APIs for process injection?
Discovering Related APIs
Say we wanted to find all the APIs related to file paths (files based on a path string and not a file handle), based on our knowledge in the previous section we could assume many of these APIs are coded to use the parameter name lpFileName as an input parameter.
We could discover these APIs with two primary methods, one is a google search such as `"lpFileName" inurl:learn.microsoft.com` (example here), another method includes searching the SDK headers, as the function definitions there follow the naming convention (see /um/fileapi.h as an example with the function definition for CreateFileA defined with the same lpFileName parameter).
So what if I wanted to find all APIs that operate on other processes, like the section APIs do? Well, presumably they all take a process handle like ReadProcessMemory for example, note how the process handle has the parameter name hProcess, however this is in the kernel32 abstractions, note how the process handle name differs in Nt APIs like ZwTerminateProcess here, which uses the name ProcessHandle instead.
Different subsystems or component groups on Windows may follow their own naming conventions.
Assuming I want to find the native Nt APIs that operate on other processes, a modified google search to search documentation for ProcessHandle would look like this example, if we wanted to tailor it for memory operations, we could add an extra keyword “memory”, the resulting google search would now look like this.
If you follow the link above you’ll note the presence of our target API ZwMapViewOfSection on the first page of our results.
When Reverse Engineering Matters
Reverse Engineering is a powerful skill in understanding the inner workings of APIs (including discovery of undocumented features) and for the discovery or self-documentation of undocumented or hidden APIs, it’s also a skill we love exercising, especially when combined with automation and scripting capabilities for batch analysis.
However it’s not the only technique or skill that can be used to discover useful APIs for malware or offensive tool development as demonstrated.
