Introduction
System calls are the ultimate high-level atomic actions that Malware writers might control. System calls sequences are the defacto ultimate way to divide behaviors between good and bad. For example the system call “encrypt” could be used by a privacy oriented software to encrypt content before shipping-it to a cloud storage or it could be used by a threat actor to encrypt victim files before asking for a ransom. The system call sequence is a fundamental subject to be studied and tested in to decrease the attack success rate . In 2015 Raymond C. et Al. in the paper titled “System Call-Based Detection of Malicious Processes” (HERE) made a nice work in figuring out what are the most successful feature set to be used in a detection engine.
“Logistic regression and support vector machines consistently outperform log-likelihood ratio and signature detectors as processing and detection methods. A feature selection study indicates that a relatively small set of system call 3-grams provide detection accuracy comparable to that of more complex models. A case study indicates that the detection system performs well against a variety of malware samples, benign workloads, and host configurations.”
In 2019 Goenka S. et Al. from University of Maryland (Baltimore Capus) made a nice master degree thesis on that topic (“Automate the tracing of Windows System Calls to identify malicious activities” available HERE) focusing on the most interesting system calls to be hooked for introspection.
Today I would like to propose a personal blog post on this topic focusing on how many different system calls in Microsoft Windows 10 could hide potential vulnerability due to their complexity. The questions that I am trying to answers are: “Is there ony a single way to reach a syscall endpoint ?”. “If we do have more ways to reach the same endpoints what are their ?”. “SysCalls endpoints are the same in both system32 and wow64 ?” and so on and so forth. But before getting into the core of the questions, let’s try to focus a little bit on most interesting syscalls for attackers.
(in)famous system calls
I know, the paragraph title is pretending. (in)famous system calls are not malicious calls per-se, but contrary they often are abused by malware writers in order to gain profit and targets, so we cannot define infamous and famous system calls, system calls are just system calls :D, but allow me to classify them in this fancy way for this time..
Registry
Those system calls are used to interact with registers. Getting persistence, avoiding multiple runs and storing malicious content (for instance piece of malware or malware secretes) are only some of the frequent usage of such a functions. Here the list:
• RegCreateKeyExA
• RegCreateKeyExW
• RegSetValueExA
• RegSetValueExW
• RegCreateKeyA
• RegCreateKeyW
• RegDeleteKeyA
• RegDeleteKeyW
• RegCloseKey
System
Widely used to interact with memory, to inject process to hollowing new process or to freeze AV processes. They also are used to interact with file system to read files and to copy and move malicious content once dropped from network or from themselves. Here the list:
• CreateToolhelp32Snapshot
• CreateProcessA
• CreateThread
• CreateFileA
• CreateFileW
• OpenFile
• DeleteFileA
• DeleteFileW
• OpenProcess
• CreateRemoteThread
• CreateRemoteThreadEx
• WriteProcessMemory
• ReadProcessMemory
• NtOpenFile
• NtCreateFile
• NtRenameKey
• WinExec
• LookupPrivilegeValueA
• LookupPrivilegeValueW
• ExitWindowsEx
Hooking Apis
Often used by threat actors or by malware developers to figure out the running system, avoiding detection and in some new fashion code to adapt evasion techniques. Here the list.
• SetWindowsHookExA
• SetWindowsHookExW
• CallNextHookEx
• UnhookWindowsHookEx
• GetAsyncKeyState
• GetKeyState
• GetKeyboardState
Crypto
Nowadays abused by Ransomware (but not exclusively) to encrypt content, to manage encryption processes and to obfuscate malicious content avoiding detection. Here a synthetic list:
• CryptBinaryToStringW
• CreateEventA
• CreateEventW
• CreateEventExA
• CryptDecrypt
• CryptEncrypt
• CryptDecryptMessage
• CryptEncryptMessage
WinSock and Network
Widely abused to send and to receive content from network. In twenties century malware abused to communicate to their C2. Here an incomplete list:
• socket
• send
• recv
• listen
• connect
• bind
• gethostbyname
• gethostbyaddr
• URLDownloadToFile
• HttpOpenRequestA
• HttpOpenRequestW
• HttpSendRequestA
• HttpSendRequestW
• InternetConnectA
• InternetConnectW
• InternetCrackUrlA
• InternetCrackUrlW
• InternetOpenA
• InternetOpenW
• InternetOpenUrlA
• InternetOpenUrlW
Debugging
Nowadays often abused by malware developers to evade dynamic analyses. A very short and incomplete list ahead.
• IsDebuggerPresent
• CheckRemoteDebuggerPresent
• OutputDebugStringA
• OutputDebugStringW
Resource
Injection, dynamic dll importing, process hollowing, and etc.. are only some of the most way to abuse those
• SecureZeroMemory
• memcpy
• wmemcpy
• memcpy
• wmemcpy
• VirtualProtect
• VirtualProtectEx
• VirtualAlloc
• VirtualAllocEx
• VirtualQuery
• VirtualQueryEx
• LoadLibraryA
• LoadLibraryW
• LoadLibraryExA
• LoadLibraryExW
Analysis
Now, my question is: “where are those system calls ? Are they localized into specific libraries ?” In other words, are those functions replicated, distributed and, for such a reason, difficult to be managed or are they localized in well-known places and easily manageable ?
I began with a simple research on my Win10 box. The research was quite straight forward by looking for (.*password)(.*change) on exporting tables in every file belonging with system32. The following image shows all the functions and the .dll that “interact” with “password change” function.
Many functions interacts with the password change. You now might wonder: “What so on?”. So, now try to imagine if you are hunting password changes, or if you are looking to hook some APIs in order to know if a password has been changed and eventually how has been changed, from whom and so on. You have plenty of ways to know that information. If your security vendor does not know all these possible hooks, it might be unable to track a malicious activities.
What about command executions ? How many possible entry points do we have in windows ? So let’s try to perform the same search by looking for import tables and the export tables firstly on system32 and later on wow64. The following image shows the ways to run ShellExecute. It looks like we have SHELL32.dll,WindowsStorage.dll,CMDEXT.dll, unbd.dll, migisol.dlland shlwapi.dll exporting function that pretend to run shell commands.
In WOW64 we have one more library called SHLWAPI.dll which looks like beiong like to run shell commands (as the following image shows). But those functions are not the only one who might allow direct code execution on a given machine.
Indeed we have way more functions to be used, for example WinExec which is exported in both versions system32 and WOW64 only by kerner32.dll but imported in different ways. On WOW64 we see more importing entrypoints while in system32 just three of them. This asymmetry could underlying an high manageable complexity. Usually where complexity is high, higher is the probability to spot vulnerability on it. The following image shows the complete list on WOW64
While the following image shows the complete list on sys32
We might replicate this research over and over again finding keywords or finding interesting system calls used by cybercriminals to develop malware. For example the following image shows the adminprivilege system calls.
The following image shows the API that could be used to download files from network.
While the following images show the many different ways to interact with the file system, divided between system32, systemWOW64 and driver.
Conclusions
Complexity hides vulnerabilities, and operative systems like Microsoft have increased their complexity over time due to compatibility tactics, longevity and new feature visions over the vast amount of different scenarios that have been involved during its history. It looks like there could be many ways to perform the same action. Many possible entry points to detect and to intercept specific events, more system calls to hook for malware developers and many knowledge to be implemented on defensive technologies. During this blog post I decided to share a quick research on windows library entry points that could be useful to everybody wants to hook and intercepts malicious behaviours based on system calls flows.
