You are browsing the archive for Anti-*.

Coalescable Timers – yet another possible anti-* API

June 16, 2018 in Anti-*, Sandboxing

I was reading about coalescable timers today and it occurred to me that:

a) there is not that much info about them online

b) I have not seen them being mentioned in a context of anti-* evasion (sandbox, reversing).

Quick googling didn’t bring many results, so I guess I will make a note here.

What are Coalescable Timers?

They are not that much different from your regular timers that one can set up using the SetTimer function, except they allow the processor(s) to better manage the resources. Basically, if you have a bunch of software that uses timers, they will end up being quite noisy and will keep popping up forcing the processors to exit the idle mode (so that the software can handle these events).

Many apps don’t really need precise timers that badly; they are often more interested in doing something every once in a while, but very precise intervals between these activities are really really rarely needed. And such regular ‘attention seeking’ is quite expensive, especially for portable devices that need to preserve the battery. So the idea is that instead of using such demanding timers one can set up a timer that can be triggered with a bit of a delay. This way, processor seeing a number of timers triggering can combine all of these falling within a certain threshold into a single event that can notify all the software ‘looking for the attention’ at once. I am simplifying it, but that’s more or less the idea.

The concept is good, and there is an API for it.  It is called SetCoalescableTimer and is present in Windows 8 and Windows Server 2012. Quick look at its implementation shows that it’s just a redirected call to… NtUserSetTimer inside the ntdll.dll. Notably, there is also a kernel function KeSetCoalescableTimer.

And here’s the funny bit.

The SetCoalescableTimer is a true Schrödinger API – it is both documented (I provided the link to MSDN above) and not (most of the information I could find leads me to believe that the proper way to use coalescablee timers is to rely on a completely different API: SetWaitableTimerEx! And this one was available in Windows 7 and Windows Server 2008 R2). Most likely someone let the SetCoalescableTimer out of the bag and now it’s there for anyone to abuse it. At the moment even Windows 10’s Windows Explorer is using it, so it’s probably not going away that soon…

Enter Sandbox – part 16: The symbols, the ApiSetSchema, and other possible future evasions

June 2, 2018 in Anti-*, Anti-Forensics, Sandboxing

It’s been a while since I wrote about Sandboxes and I thought I will revive the series by listing a couple of ideas that I believe may be still under the radar of both sandbox solution creators, and reverse engineers.


When we analyze Windows native OS libraries one of the most useful features we have at hand is leveraging debugging symbols. IDA, windbg, and many other reversing tools can use these symbols very efficiently – with symbols in place we can see names of internal functions, variables, and this code/data enrichment provides us with an invaluable context that speeds up the analysis.

Now, since the tools can use it, there is nothing that could stop malware from… doing the same.

Imagine the possibilities!

Instead of relying on export/import tables, a clever malware that leverages symbols could make calls to internal functions, or find ways to hook code deep inside the functions that are typically monitored (at least on the userland level). Symbols could also help to detect caves i.e. areas of code/data that are rarely used, and allow malware to overwrite them and persist in a much stealthier way than usual. There is a lot of potential for surgical modification of code to launch the payload code using the EPO (Entry Point Obscuring) technique.

Note that while there could be a need to download these PDB files directly on the infected system, nothing stops malware from sending copies of the DLLs from the system to its server first, decompiling / disassembling them on a remote server.  The malware could then craft the payload using hardcoded offsets obtained via symbols to deliver the required functionality. A side effect of such trickery would be that such crafted payloads would not run on sandboxes, and manual analysis would typically fail unless the file was analyzed on the exactly same system (meaning: with the same versions of libraries as existing on the victim’s system); obviously, ASLR needs to be taken into account for all offsets and calls. Another caveat is that such approach would require constant monitoring of Windows Update service; if files are replaced, the code would need to be updated to the most up to date version that works with the new libraries.

Leveraging functions of ApiSetSchema libraries

Now that we have not only kernel32.dll, but also KernelBase.dll, and the whole api-ms-*.dll zoo, it is possible to call these wrapper functions instead of the pure exports from kernel32.dll, advapi32.dll, etc..

Leveraging internal/undocumented functions

These can be either located via symbols, or via ApiSetSchema libraries; a quick browsing through internal functions referenced by kernel32.dll reveals a lot of interesting possibilities e.g.:

  • PrivCopyFileExW – undocumented function that allows to copy files
  • A couple of exported Internal functions that can be potentially used as callbacks (to run shellcodes, payload code, etc.)
    • Internal_EnumCalendarInfo
    • Internal_EnumDateFormats
    • Internal_EnumLanguageGroupLocales
    • Internal_EnumSystemCodePages
    • Internal_EnumSystemLanguageGroups
    • Internal_EnumSystemLocales
    • Internal_EnumTimeFormats
    • Internal_EnumUILanguages
  • A couple of exported Internal functions that can be used to access both the Registry and the File System bypassing documented APIs:
    • RegCreateKeyExInternalA
    • RegCreateKeyExInternalW
    • RegDeleteKeyExInternalA
    • RegDeleteKeyExInternalW
    • RegOpenKeyExInternalA
    • RegOpenKeyExInternalW
    • ReplaceFileExInternal

There is certainly more.

New technologies (well, sometimes not that new)

While it doesn’t really rely on symbols, it does fit the topic of the article – there is a class of APIs that are not commonly used yet, but certainly will be heavily utilized in the future:  I am talking about enclave functions; as per MS:

An enclave is an isolated region of code and data within the address space for an application. Only code that runs within the enclave can access data within the same enclave.

Example functions:

So, you got yourself yet another API set for both code injection and protection.

I am obviously not the first one to highlight it; a paper from 2015 (3 years ago!) by Alex Ionescu covers the topic and lists a number of possible issues enclaves bring to the world of security solutions including AV, EDR, and perhaps memory acquisition tools.