CISO Summary

It’s a case of hiding in plain sight. CofenseTM recently found a phishing campaign that hides the Kutaki malware in a legitimate application to bypass email gateways and harvest users’ credentials.

A data stealer, Kutaki uses old-school techniques to detect sandboxes and debugging, but don’t underestimate it—Kutaki works quite well against unhardened virtual machines and other analysis devices. By backdooring a legitimate application, it can fool unsophisticated detection methodologies.

Learn how Cofense IntelligenceTM keeps IT teams ahead of the latest phishing and malware threats like this new campaign.

Full Details

Cofense Intelligence recently uncovered a small-scale phishing campaign delivering a sample of the Kutaki information stealer and keylogger that was hidden inside a legitimate Visual Basic application and delivered as an OLE package within a weaponized Office document.

Kutaki uses a series of anti-virtualization and anti-analysis techniques that were ostensibly copied verbatim from a series of blogs dating back to 2010-2011 (Appendix: sources) . Kutaki – a data stealer – is capable of harvesting Input data directly from keyboards, mice, clipboards, microphones, and screens (in the form of screenshots). The campaign observed by Cofense Intelligence also saw Kutaki retrieve a copy of SecurityXploded’s BrowserPasswordDump utility by dropping and executing a copy of cURL for Windows.

Despite the evasion techniques being antiquated, they are somewhat successful against causal observation and analysis.

Hiding in Plain Sight: Obfuscation

This variant of Kutaki uses the source code as a Visual Basic training app to hide its malicious content. By backdooring an ostensibly simple training app, it attempts to exploit any potential whitelisting or simply bypass static signatures.

Figure 1 shows the backdoored application as a project breakdown. Figure 2 is a closer view of the procedures.

Figure 1: the project breakdown

Figure 2: The code sections (procedures) present in the project.

Even for non-programmers, there are certain procedure names that seem to be wildly misplaced. Indeed, we can see a close (but not quite complete) correlation between the Forms – which are GUI elements – and the procedures that power them. Figure 3 demonstrates this mapping.

Figure 3: Form elements relative to their procedure (code) counterparts.

Final proof that this application has been backdoored can be found by inspecting the procedures. Figure 4 shows legitimate procedures compared with those that have been injected.

Figure 4: “ff” and “frmLogin” are original procedures. “chee”, “saamneao”, “dewani” and “ende” are injected.

Not only do we see a discrepancy between the naming conventions – most legitimate procedures here begin with ‘frm’ – but we can also intuit the random names assigned to the injected procedures. Further, the functions – those found within the injected procedures – have unresolvable names, so they’re simply assigned one by the decompiler.

Diving into some of this injected code yields even more obfuscation. Strings within the binary are reversed and decoded using the rtcStrReverse function. Figure 5 shows an example of such obfuscation.

Figure 5: 3 instances of rtcStrReverse being used to deobfuscate stored strings.

Similar string obfuscation techniques can be found masking suspicious API calls. Figure 6 shows the obfuscation of Sleep and ShellExecuteA strings.

Figure 6: Sleep and ShellExecuteA strings.

These strings are part of a small struct used by DllFunctionCall – a method by which Visual Basic applications can retrieve the addresses of functions from specific DLLs. The struct looks something like this:

typedef struct _DllFunctionCallDataStruct {

void * lpLibName;

void * lpExportName;

} DllFunctionCallDataStruct;


We can see how this structure maps to what we see in the disassembly in figure 6. All calls to DLLFunctionCall are wrapped in identical snippets, as demonstrated in Figure 7.

Figure 7: a typical wrapper for calls to DllFunctionCall.

After careful analysis, we find that 18 high-value API calls are obfuscated in this manner. Figure 8 details these.

Figure 8: De-obfuscated API calls used by Kutaki to perform some of its malicious activity.


Kutaki employs some basic checks and comparisons to identify whether it is executing within a virtualized environment. The first of these involves reading the HKLM\System\CurrentControlSet\Services\Disk\Enum registry key and comparing the returned string against a list of “undesirable” strings. Figure 9 details the read of this key.

Figure 9: Kutaki reads disk metadata from the registry.

This registry key contains information about the disks present on the machine. The first disk is stored in a value named “0”, the second in a value named “1” and so on. In the instance of this  analysis VM, the value 0 contains the data observed in figure 10.

Figure 10: Example data from the Disks\Enum registry key.

The highlighted text shows that the disk belongs to a VirtualBox VM. Figures 11 and 12 show two different string comparisons, attempting to identify different types of virtual machines present. Figure 13 is all the strings Kutaki will compare against.


Figure 11: Check if the registry value contains “VIRTUAL” anywhere within the string.

Figure 12: Check if the registry value contains “VBOX” anywhere in the string.

Figure 13: Anti-virtualization strings.

The string comparison seen in figure 12 would match the data found in the registry value displayed in Figure 10. Despite the match, Kutaki doesn’t immediately exit, rather it continues with other virtualization checks. Only after all checks are completed will it determine whether execution should continue. Figure 14 shows the execution flow of this concept. The specifics of the results checker are detailed later.

Figure 14: Anti-analysis/virtualization chain.

To supplement the disk checks, Kutaki attempts to determine whether specific modules, which belong to sandboxes and debugging utilities, have been injected into its address space. It achieves this by using a combination of CreateToolhelp32Snapshot, Module32First and Module32Next. These APIs take a snapshot of the running process (including heap, modules, etc.), find the first module, and iterate over subsequent modules mapped to the process, respectively. Figure 15 shows Kutaki setting up the snapshots and retrieving a pointer to the first module.

Figure 15: Kutaki setting up a module-identification loop.

Kutaki checks for the existence of sbiedll.dll and dbghelp.dll. These modules belong to Sandboxie and Microsoft, respectively. Figure 16 shows the de-obfuscation and comparison routine for dbghelp.dll.

Figure 16: Windows Debug DLL de-obfuscation and string comparison.

All the comparison results are stored in a data structure, which is later checked by the _check_anti_analysis routine.

In a final check to ensure it is not being observed, Kutaki once again reads a registry key — HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion — this time checking for the existence of some very specific ProductID values within the CurrentVersion hive. Figure 17 shows this function.

Figure 17: Opening the registry key to facilitate value comparisons.

Kutaki attempts to find a value with the name “ProductID”. If it finds one key with that value, it will loop through three string comparisons, attempting to identify three sandbox platforms. Some pseudocode to roughly describe this process could be:


p_id = RegQueryValueExA(“ProductID”)

if (p_id)){

if (p_id == ‘76487-337-8429955-22614’) {

return “Anubis”


elif (p_id == ‘76487-644-3177037-23510’) {

return “CWSandbox”


elif (p_id == ‘55274-640-2673064-23950’) {

return “JoeSandbox”


else {

return None




Figure 18 shows this nested loop as it exists with Kutaki.

Figure 18: Looping through checks for various sandboxes.

Once all of the checks have been processed, Kutaki parses the results to determine if its main loop should finish or continue executing. The check procedure parses every result for a non-zero “return code” (i.e. something was detected) and, if it such a return code is found, the main loop exits. Figure 19 shows an example of these checks.

Figure 19: Parsing the results of one of the anti-analysis checks.


Once Kutaki has determined it is not being monitored, it will proceed with its primary purpose of preparing the machine for data-theft. During this process, Kutaki extracts an image from its resources, drops it to the user’s temp directory and launches it with ShellExecuteA(“cmd.exe /c C:\Users\admin\AppData\Local\Temp\images1.png”). This displays a decoy image to fool the user into believing the OLE package they clicked on was simply an image. Figure 20 is the precise image dropped to disk and displayed to the user.

Figure 20: Decoy image launched by Kutaki.

The document is an invoice template; clearly the actors deploying this put very little effort into this decoy document, as a quick Google search shows it to be the second image hit using the search term “tax details to invoice”. Indeed, this is the exact image used by the attackers: hxxp://batayneh[.]me/invoice-with-bank-details-template/invoice-with-bank-details-template-blank-tax-luxury/

After displaying the document, Kutaki checks its current executable name against the hardcoded string “hyuder” and, if it does not match, proceeds to drop a copy of itself, with the new name, to


C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\hyuder.exe


Figure 21 shows this check in a debugger. If a new process is launched, the parent process will sit idle without exiting.

Figure 21: Kutaki comparing its current name to the desired.

Figure 22 shows Kutaki building the file path to which it will drop a copy of itself. By dropping to the startup folder, Kutaki achieves persistence.

Figure 22: Kutaki builds out the string it will use to drop a copy of itself and achieve persistence.

Kutaki executes the dropped code and proceeds to execute its primary malicious functionality. Note: some readers will no doubt question whether simply renaming the executable “hyuder.exe” will prevent it from dropping a copy of itself. This is correct; Kutaki will execute directly without dropping anything further, if it is running with an approved name. The rest of the code is somewhat uninteresting, mostly because almost all the malicious behavior occurs outside of the binary itself.

Before proceeding further, Kutaki will check in with its C2 server, announcing the new infection. Figure 22 is some example traffic observed during analysis.

Figure 23: Kutaki’s C2 server is offline.

Kutaki also comes bundled with a copy of cURL – a Linux app ported to Windows which allows command line access to internet resources. It uses cURL to retrieve a payload from a remote host, although quite why it does this is unclear – it has the capability to contact remote servers as demonstrated by its initial attempt to contact its C2 server. Regardless, the use of cURL is by design, as the host from which it attempts to download a further payload refuses connections unless the User Agent is set to one referencing cURL. Figure 23 documents the connections made by cURL to the remote host, retrieving a secondary payload.

Figure 24: Kutaki uses cURL to download and execute a secondary payload. Note the User-Agent string “curl/7.47.1”.

The payload retrieved, in this case, was a copy of SecurityXploded’s BrowserPasswordDump. This utility is designed to retrieve passwords from the vaults of the following browsers:

  • Firefox
  • Google Chrome
  • Microsoft Edge
  • Internet Explorer
  • UC Browser
  • Torch Browser
  • Chrome Canary/SXS Cool
  • Novo Browser
  • Opera Browser
  • Apple Safari

Because the C2 server was offline, we were unable to monitor the exfiltration of stolen data facilitated by the BrowserPasswordDump utility.

Old Does Not Mean Ineffective

Kutaki uses some old-school, well-documented techniques to detect sandboxes and debugging. These are still effective against unhardened virtual machines and other analysis devices. Additionally, by backdooring a legitimate application, unsophisticated detection methodologies could well be fooled.

To learn more about recent malware trends, read our 2018 year-end review.




ProductID Checks

76487-337-8429955-22614 // Anubis Sandbox

76487-644-3177037-23510 // CW Sandbox

55274-640-2673064-23950    // Joe Sandbox


AntiVM Strings

















All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.