SANS ISC: Defenders, Know Your Operating System Like Attackers Do! - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Not a technical diary today but more a reflection… When I’m teaching FOR610[1], 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 VirtualAllocEx()[2] which allocates a region of memory within the virtual address space of a specified process:

LPVOID VirtualAllocEx(
  HANDLE hProcess,
  LPVOID lpAddress,
  SIZE_T dwSize,
  DWORD  flAllocationType,
  DWORD  flProtect
);

hProcess is a handle to a process returned by OpenProcess(). Then, you use WriteProcessMemory() to write specified contents into the memory of the targeted process. When you read this, you can ask yourself: “Wait… why does Microsoft allow a process to inject code into another process?”. The answer is simple: because it’s a key feature of the operating system and it can be used for many totally legit reasons. Think about antivirus programs! It’s common that AV injects code into processes of a process (ex: in browsers to inspect downloaded data).

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 VirtualProtect, check the last parameter:

LPVOID VirtualAlloc(
  LPVOID lpAddress,
  SIZE_T dwSize,
  DWORD  flAllocationType,
  DWORD  flProtect
);

flProtect allows you to set the memory protection for the region of pages to be allocated. If you see the value 0x40 (PAGE_EXECUTE_READWRITE) set for this parameter, it means the newly allocated memory will contain executable code![3]

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:

• Code injection
• DLL operations
• Dropping 2nd stage
• …

In my triage process, I use FLOSS[4] 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[5].

Happy hunting!

[1] http://for610.com
[2] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualallocex
[3] https://docs.microsoft.com/en-us/windows/win32/memory/memory-protection-constants
[4] https://github.com/fireeye/flare-floss
[5] https://github.com/xme/yara-rules/blob/main/suspicious-api-calls.yara

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key