Not a technical diary today but more a reflection… When I’m teaching FOR610, I always remind students to “RTFM” or "Read the F… Manual". I mean to not hesitate to have a look at the Microsoft document when they meet an API call for the first time or if they are not sure about the expected parameters.
Many attackers have a very deep knowledge of how targeted operating systems are behaving and what are the controls in place or features that could be (ab)used by malicious code. When you’re analyzing malware samples, it’s very important to quickly spot interesting blocks of code (by learning which interesting OS feature they use). A classic example is the API call
LPVOID VirtualAllocEx( HANDLE hProcess, LPVOID lpAddress, SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect );
API calls are a key aspect of malware, not only the function itself but also its options. Here is another example: If you see a
LPVOID VirtualAlloc( LPVOID lpAddress, SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect );
An approach to flag some sample during the triage process is to identify the group of API’s that are used to perform suspicious actions like:
In my triage process, I use FLOSS because it can extract a lot of API calls from strings, stack strings, etc… Then I parse the output to YARA to match interesting groups of API. Example:
remnux@remnux:/MalwareZoo/20210316$ floss sample.exe | ./yarawrapper.py suspicious-api-calls.yara Matching: api_address_search Matching: dll_operations
Why YARA? Because it helps to create useful rules like "any of this", "all of this", and, or, groups of APIs. A sample of YARA rules is available here.
Xavier Mertens (@xme)
Mar 17th 2021
|Thread locked Subscribe||
Mar 17th 2021
4 months ago