You are browsing the archive for Malware Analysis.

Returning the call – ‘moshi moshi’, the API way (a.k.a. API cold calling)

July 31, 2016 in Anti-*, Malware Analysis, Reversing

Software development is quite easy today. There is no longer a need to write your own libraries for everything (a mouse handler, a proprietary database, a graphics library, or your own search and caching algorithms, etc.). What’s more, a very complex functionality can be now delivered with just a few lines of script.

Yup. We are indeed very lucky.

While we depend on these modules to do the hard work we happily focus on the business logic and simply getting things done. But yes, of course, this privilege relies heavily on a tremendous work of other programmers who developed and tested modules which we use every day. Modules that are the foundation of Windows as we see it today have been written over a few decades (maybe with the exception of telemetry modules ;)) and it’s not a surprise that many of them contain legacy code, vulnerabilities, and… dummy, retired, or unfinished code.

In this post I will focus on the latter – the APIs that are pretty much doing nothing, but returning an error or a predictable constant value (I will talk about 32-bit Windows, but same applies to 64-bit version). Either indicating that the function is not implemented yet, or is just a dummy function kept for compatibility reasons, or perhaps for some other reason. I won’t cover all of them, but will show a few examples of how these could be used.

  • Probably the best known function that returns a constant value is kernel32.dll!GetCurrentProcess. It simply returns -1 (0xFFFFFFFF on win32). For this reason many programmers hard-code this value in their programs (one API call less).
  • Its close cousin, kernel32.dll!GetCurrentThread always returns -2. Same, some coders hard-code it to avoid superfluous API calls.
  • crypt32.dll!DbgPrintf always returns 0. So does imm32.dll!CtfImmIsTextFrameServiceDisabled. And tones of other APIs. A nice ‘obfuscated’ replacement for the worn out ‘xor eax, eax’.
  • gdi32.dll!GdiSupportsFontChangeEvent always returns 1. So does kernel32.dll!LZStart. And again, lots of other APIs.
  • GdiPlus.dll!GdipCreateStreamOnFile aways returns 6.
  • rasman.dll!RasRpcUnloadDll always returns 50.
  • atl.dll!AtlGetVersion returns 768 on Win10..
  • Many unimplemented APIs return ERROR_INVALID_PARAMETER which is equal to 87 f.ex. dnsapi.dll!DnsUpdate and dnsapi.dll!Dns_UpdateLibEx.

This can be obviously extended to COM and its methods that do nothing, but returning ‘not implemented’ constants.

The other variants of this technique can utilize fully implemented APIs which are called with incorrect arguments producing a predictable last error value.

There are a number of potential tricks we can pull using APIs returning predictable, or very specific values, or behaving in a predictable way:

  • anti-emulation tricks
    • initialization of register values – if an emulator fails to emulate the function it may not get the proper value into the eax register and as such a code dependent on it may fail (f.ex. a decryption routine, a routine using the return value as an index to a lookup table, etc.)
    • passing data by storing it inside the internal OS structures f.ex. SetLastError/ SetLastErrorEx  / GetLastError combo
  • detecting the version of OS
    • historically, some APIs changed the behavior and newer versions may simply return a constant f.ex. TRUE (1); a simple example is GdiSetAttrs (probably not very practical example as its behavior changed long time ago, but always…)
    • new APIs can help to detect OS version w/o using ‘traditional’ APIs (f.ex. Get Version, etc.) – relatively new ole32.dll’s CoBuildVersion function could be used to determine the version of ole32.dll (and indirectly, OS version); same goes for UrlMkBuildVersion exported by urlmon.dll
  • anti-debugging tricks
    • if the function does nothing, but calling DebugBreak (int 3), it may fool some analysts by triggering the exception handler w/o them noticing it (lame, but always)
  • perhaps others…

Beyond good ol’ Run key, Part 43

July 28, 2016 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

Testing, testing, testing… such an important part of the software development cycle. So important that its components are often referenced in the release code.

The testing functionality in Microsoft products is nothing new. I wrote about it here, and here. And today I will write about yet another component which appears to be testing-related and… can be abused to achieve persistence. This time, on Windows 10 only (have not tested servers).

When Windows 10 accepts the remote desktop session, it queries the following Registry key:

  • HKLM\SYSTEM\CurrentControlSet\Control\
    Terminal Server\AddIns\TestDVCPlugin

If such key exists, the OS will attempt to read the Path value underneath.

Once the Path is read, the DLL that it points to will be loaded via LoadLibrary.

And that’s it! We now have yet another persistent mechanism to load the DLL. Anytime the first remote desktop session is established…

An example of the potential malicious Registry Entry is shown below:

TestDVCPlugin0

In a test scenario, I created a DLL that – when loaded – creates a c:\test\test_attached file.

The following screenshot shows what happens:

  • The user is logged on (console session) – the two first commands show situation at that moment and no presence of the file created by the DLL
  • The user then logs on remotely (under the same account – rdp-tcp#1 session).
  • The moment user logs on, the c:\test\test_attached file is created – the code is loaded

TestDVCPlugin1

The c:\test\test.dll is loaded into svchost.exe process and stays resident (until reboot/service restart)

TestDVCPlugin2