Aug 17, 2014
Breaking News: Sed ut perspiciatis, unde omnis iste natus error sit voluptatem accusantium doloremque laudantium

Tag: trojan


00Malware, Malware analysis, Phishing, TrojanTags: , , , , ,



In January 2016 Forcepoint Security Labs reported an email campaign delivering the Ursnif banking Trojan which used the ‘Range’ feature within its initial HTTP requests to avoid detection.

In July 2017 we discovered a malicious email sample delivering a new variant of Ursnif, attached within an encrypted Word document with the plaintext password within the email body. As recorded in several other Ursnif campaigns reported since April 2017, this Word document contains several obfuscated VBS files which load malicious DLLs through WMI.

However, these samples appear to exhibit new features including anti-sandboxing features that use a combination of mouse position and file timestamps to decode their internal data and the ability to steal data from the Thunderbird application.



A sample lure email for this campaign is shown below:

Once decrypted, it shows three OLE document icons with the extension “docx”, which will lure users to double click them directly (see below):

In fact, their file properties show they are three identical VBS scripts, including same highly obfuscated code padded with lots of garbage scripts to cover up normal logic.

Once triggered, it tries to download malware from ‘hxxp://46.17.40[.]22/hyey.pnj’. If this fails, a second attempt will be made to another site: ‘hxxp://inshaengineeringindustries[.]com/head.pkl’. These files are in fact DLL files which have been designed to be loaded through WMI:

rundll32 [malwarepath] DllRegisterServer

This malicious DLL is packed and again padded with lots of garbage code to hamper static analysis attempts. During execution, it will drop a second DLL file, map this new DLL to the current address, fix the Import Address Table and Relocation Table, then finally jump into the entry point to execute.

The dropped DLL first does self-checking on integrity and then:

  • Performs anti-sandboxing checks
  • Performs anti-VM checks
  • Implements persistence through an autorun registry key
  • Injects itself into the ‘explorer.exe’ process

The remainder of this analysis will focus on the new mouse-based anti-sandboxing/decryption capabilities.

Anti-Sandboxing Checks

The algorithm used by this sample uses the difference between the current and previous recorded mouse coordinates to detect mouse movement and avoid sandbox environments where the mouse is not usually moved. It further uses the value generated by this process to ‘brute force’ its own decryption key.

Step One – Key Generation

Firstly, the malware calculates the D-Value (delta) between the x- and y-coordinates of the last and current mouse position. It then selects the sum of the .BSS section’s Relative Virtual Address (RVA) and ‘SizeOfRawData’ value as a base seed.

It XORs the base seed with the file creation time (in this case ‘Apr 11 2017’) to get a value which is added to the lowest 5 bits of the mouse D-Value to get the decryption key.

Step Two – Decode .BSS Section

The malware loops through the .BSS section of the DLL one DWORD at a time, XORing the current DWORD data with the last DWORD data. This value is then XORed with the decryption key generated above and right-rotated by the loop count. The ‘current’ DWORD is then replaced.

Step Three – Verify The Deciphering Key

After .BSS section data is decoded, three values are acquired from offsets 0x61d, 0x619, and 0x625 in the .BSS section, and their sum compared with checksum ‘0EE553B4E’. If this matches, it will execute the rest of the code, otherwise it has to restore the encrypted .BSS section raw data and try to re-calculate new key for another attempt at the decryption and verification operation.

If run in sandbox environment, since the D-value based on the mouse movement always is 0, the ‘BSS’ section is always inaccurately decoded and will loop execution of same code. While in a realistic environment, due to only using the lowest 5 bits of D-value rather than the full 32 bits, it is more likely to get correct value to decode section data.

The decryption key itself is an important global constant which will be used in subsequent code to decode APIs, a hidden PE file (DLL file in this variant), synchronous objects, Registry data, URLs, etc.

In addition, the decoding operations are implemented at run time, preventing memory analysers from dumping the whole plaintext string stream of malware memory, e.g.

Decoding Windows APIs used for further injection operations:

With the aid of the decryption key, an additional embedded PE file (a 3rd DLL file) can be safely extracted from data section of the second DLL file, released to a temporary buffer, and injected into the ‘explore.exe’ process.



Ursnif spreads itself through emails provided with a plaintext password for an attached encrypted document. In general, this method is used by senders when the attached documents contain sensitive content. In recent years, this method is widely leveraged by threat actors, who want to ensure their payload successfully bypasses IDS detection and to deceive recipients to firmly believe that the mail may contain important information.

Overall, Ursnif is well concealed: it communicates with C2 servers via Tor, limiting its traceability, and is equipped with anti-sandbox and anti-VM techniques.

You value our work? Please support us 


TrickBot Loader – inside the trojan

00Latest news, Malware, PhishingTags: , , ,


According to Limor Kessem, executive security advisor at IBM Security, “unlike its predecessor, Dyre, TrickBot has “dabbled” in malvertising, leveraging the RIG exploit kit, malicious email attachments and poisoned Office macros coming through the “Godzilla loader”. That behaviour suggests that the group behind TrickBot is after specific business accounts. They have been sending malware-laden spam to companies, not just indiscriminate waves of email.” This is another new feature which Dyre did not contain.

Experts agree that although there are quite a few similarities, TrickBot has been rewritten with a different coding style and minor changes have been made to upgrade the code rather than reinvent the wheel. Similarities include, loaders and custom encryptors, similar hashing features, and an upgraded command and control encryption tool.

TrickBot contains more C++ code, compared to Dyre, which mostly used C. The new Trojan also uses the Microsoft CryptoAPI instead of built-in functions for AES and SHA-256 hashing algorithm (a kind of unique signature for a text or data file – also used by Bitcoin). Dyre ran commands directly, whereas TrickBot links with the Task Scheduler through the COM standard for more impact.

TrickBot has made its way into the banking sector over recent months by using a malvertising campaign, involving Rig Exploit Kit to disseminate its payload.

Behavioural analysis

Once deployed, TrickBot copies itself into %APPDATA% and deletes the original sample. No changes are made to the initial name of the executable file (in the below example the sample was named “trick.exe”).

Figure 1: Sourced from Malwarebytes Labs

The first thing the bot does, is drop two additional files: client_id and group_tag, which are generated locally and used to identify the individual bot and the campaign to which it belongs. There is no encryption – both files contains text in Unicode.

client_id contains: the name of the attacked machine, the version of the operating system, and an arbitrarily generated string.

In the same folder, a config.conf file is also present. This file is downloaded via Command & Control (C&C) and stored in encrypted form.

Note: Command & Control (C&C or C2) is used by attackers to maintain communications with compromised systems within a target network.

A folder, called Modules, is created in %APPDATA%. More files, called injectDll32 (the banker module, injecting DLLs into target browsers to enable theft of credentials) and systeminfo32 (used for gathering general system info), are downloaded into the same location via C&C. They are also encrypted and a list of the attacked browser is hardcoded in the injectDll32.dll.

Figure 2: Sourced from Malwarebytes Labs

Sometimes these files have an equivalent folder that stores the configurations (as seen in the diagram above). Details of the attacked target (i.e. the bank’s URL) are stored in this folder.

The bot is able to remain effective by adding itself as a task in Windows Task Scheduler. No effort is made to try and hide the task under a legitimate name – as you can see in the example, it’s simply called “Bot”.

Figure 3: Sourced from Malwarebytes Labs

If an attempt is made to kill the process, it is automatically restarted by the Task Scheduler Engine.

Network communication

The Trick Bot connects to several servers. It initially connects to a valid server, so that it gets the visible IP. Strangely, it uses its own User Agent (“BotLoader” or “TrickLoader”) and makes no attempt to disguise itself as a legitimate browser. Most of the Bot’s communication with C&C is SSL encrypted, however, some is left unencrypted.

In the URL of a POST request, group_id and client_id are used – which are the same names given to the files seen early. The command id follows after that. This was a characteristic of Dyreza.

An additional payload is downloaded (for example 47d9e7c464927052ca0d22af7ad61f5d) without encrypting the traffic. C&Cs are set up on hacked wireless routers, i.e. MikroTik, which is another feature of TrickBot that is the same as its predecessor, Dyreza.

There is absolutely no attempt made to imitate legitimate-looking names for HTTPs certificates either – they contain completely random data. For example:

Inside TrickBot

TrickBot is made up of many layers.

Figure 4: Sourced from Malwarebytes Labs


The first layer is generally the protective layer, containing the encrypted payload that tries to hide from AV software.


The second layer is the main bot loader, which selects whether to deploy 32-bit or 64-bit payload. New PE files are encrypted and stored in resources. Again, no attempt is made to hide the purpose of the resources. The names are easy to decode.

Figure 5: Sourced from Malwarebytes Labs

To start with, the application acquires information about victim’s operating system, so that the appropriate path can be chosen. Depending on the environment, a suitable payload is selected from resources, decrypted by a basic algorithm and validated. This method is slightly different to how Dyreza worked. Next, a dedicated function is used to map the unpacked bot to the memory and deploy it.

The 32-bit bot uses self-injection to map the new module inside its own memory, before redirecting execution, whereas for the 64-bit payload, the additional executable (64bit PE loader) is first unpacked and run, and then it loads the core, malicious bot. In contrast to Dyreza – where the main modules were DLLs – TrickBot uses EXEs.

In Summary

Trick Bot has a lot in common with its predecessor, Dyreza, although it does not have as many features (possibly designed that way to make distribution quicker). From comparing the code of both bots, it is clear that the offspring does not just contain a few tweaks – it has been completely rewritten and it is highly likely to gain as much fame as the former champion.

You find the info useful? 

Kazuar: Multiplatform Espionage Backdoor with API Access

00MalwareTags: , , , , ,

Unit 42 researchers have uncovered a backdoor Trojan used in an espionage campaign. The developers refer to this tool by the name Kazuar, which is a Trojan written using the Microsoft .NET Framework that offers actors complete access to compromised systems targeted by its operator. Kazuar includes a highly functional command set, which includes the ability to remotely load additional plugins to increase the Trojan’s capabilities. During our analysis of this malware we uncovered interesting code paths and other artifacts that may indicate a Mac or Unix variant of this same tool also exists. Also, we discovered a unique feature within Kazuar: it exposes its capabilities through an Application Programming Interface (API)  to a built-in webserver.

Recently, we received data shared in confidence that may link the Kazuar tool to the Turla threat actor group (also known as Uroburos and Snake), who have been reported to have compromised embassies, defense contractors, educational institutions, and research organizations across the globe. A hallmark of Turla operations is iterations of their wools and code lineage in Kazuar can be traced back to at least 2005. If the hypothesis is correct and the Turla threat group is using Kazuar, we believe they may be using it as a replacement for Carbon and its derivatives. Of the myriad of tools observed in use by Turla Carbon and its variants were typically deployed as a second stage backdoor within targeted environments and we believe Kazuar may now hold a similar role for Turla operations.

Kazuar is a fully featured backdoor written using the .NET Framework and obfuscated using the open source packer called ConfuserEx.  We used a combination of tools such as NoFuserEx, ConfuserEx Fixer, ConfuserEx Switch Killer, and de4d0t in order to deobfuscate the code for in depth analysis.  We then used dnSpy to export the code to a Microsoft Visual Studio project, so that we could rename the random method names to better understand the flow of the code. We will describe how Kazuar works and what capabilities it offers threat actors.


The malware initializes by gathering system and malware filename information and creates a mutex to make sure only one instance of the Trojan executes on the system at a time. Kazuar generates its mutex by using a process that begins with obtaining the MD5 hash of a string “[username]=>singleton-instance-mutex”. The Trojan then encrypts this MD5 hash using an XOR algorithm and the serial number of the storage volume. Kazuar uses the resulting ciphertext to generate a GUID that it appends to the string “Global\\” to create the mutex.

An interesting artifact that we found within the mutex creation process is that if the code cannot obtain the system’s storage serial number, it will use a static integer of 16456730 as a key to encrypt the MD5 hash. The hexadecimal representation of 16456730 is 0xFB1C1A, which appears to be included by the malware author as a potential reference to the United States’ FBI and CIA organizations.

The Trojan then creates a set of folders on the system to store various files created during its execution. Kazuar creates its folders using group names, which logically organize the files contained within the folder. Folder layout:

Folder Group Files Description
base Parent folder that contains the following folder groups below
sys Files that Kazuar uses for configuration settings, such as the ‘serv’ item that stores the C2 server locations
log Files contain debug messages
plg Files are plugins used to extend the functionality of Kazuar
tsk Files that Kazuar will process as commands and their arguments
res Files contain the results of the successfully processed tasks

Kazuar’s folder group names and the files stored within

The Trojan uses a similar process to create these folder and file names as it uses to generate its mutex, generating an MD5 hash of the name, using XOR on each byte using the volume serial number as a key and generating a GUID based on the ciphertext. The resulting GUIDs are used as file and folder names, which are combined with the local system path to the %LOCALAPPDATA% folder to create Kazuar’s folders.

Throughout its code, Kazuar verbosely logs its activities by writing debug messages to log files stored within the “log” folder. Kazuar encrypts the debug messages saved in these log files using the Rijndael cipher. We decrypted the initial entry that was added to the log files during the execution of the Trojan. This entry reveals the following information:

The log message above shows that the malware author refers to the Trojan as “Kazuar”. Interestingly, the word “Kazuar” appears in several languages, such as Polish, Hungarian and Slovenian, and is the ASCII form of the Russian word “казуар”. The word “Kazuar” and казуар translates to Cassowary, which is a large flightless bird native to New Guinea and Australia.

After initial setup, the method at the main entry point of the malware, as seen in Figure 2 may follow one of four main paths of execution. The main entry point contains a relatively simple set of if statements that determine the execution path of the malware. Interestingly, one of the paths appears to be for execution on a Mac or Unix host.


Figure 2: Main entry point shows if statements that control the flow of execution

The four possible paths of execution taken by Kazuar’s main entry point are as follows:

  1. If the malware was executed with the “install” command-line argument, which uses .NET Framwork’s InstallHelper method to install the malware as a service.
  2. If the malware is started in a non-user interactive environment (no user interface), the malware installs itself as a service.
  3. If no arguments are provided and the malware determines it is running in a Windows environment, it saves a DLL to the system that it injects into the explorer.exe process. The injected DLL executable loads the malware’s executable and runs it within memory of the explorer.exe process.
  4. If the malware was executed with the “single” command-line argument or the malware determines its running in a Mac or Unix environment, it runs the method containing Kazuar’s functional code and will limit certain Windows specific functionality if a Mac or Unix environment is detected.

The flow of execution is carefully guided by its operating environment, which is determined using the .NET Framework Environment.OSVersion.Platform.PlatformID enumeration, as seen in the function in Figure 3 that is responsible for gathering system specific information. Interestingly, we see a specific boolean variable for a PlatformID value of Unix that suggests that Kazuar might be used against Mac or Unix targets that return True for that API.


Figure 3. The getsysinfo() function provides various environment enumeration capabilities for Kazuar.

After enumerating the operating environment, Kazuar will attempt to establish persistent access to the system. Kazuar uses the method displayed in Figure 4 within its Autorun class to set up persistence on Windows systems, which has multiple options including:

  1. Adding a shortcut (lnk file) to the Windows startup folder
  2. Adding a sub-key to the following paths in the current user (HKCU) hive:
    • SOFTWARE\Microsoft\Windows\CurrentVersion\Run
    • SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
    • SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
    • SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
    • SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\load


Figure 4. Kazuar’s Autorun class is a Windows specific method that contains multiple options for persistence using the startup folder and registry.

Command and Control (C2)

The Kazuar Trojan initially relies on its command and control channel to allow actors to interact with the compromised system and to exfiltrate data. Kazuar has the capabilities to use multiple protocols, such as HTTP, HTTPS, FTP or FTPS, determined by the prefixes of the hardcoded C2 URLs. So far, we have only observed HTTP used as the C2 protocol in our sample set. All of the known Kazuar C2 servers appear to be compromised WordPress blogs, suggesting that the threat group using Kazuar in attacks also locates and exploits vulnerable WordPress sites as part of their playbook.

To interact with its C2 server, Kazuar begins its communication by creating an HTTP GET request to use as a beacon. The beacon, generated by the code seen in Figure 5 contains a cookie that has an “AuthToken” value that is a base64 encoded GUID used to uniquely identify the compromised system. Kazuar refers to this GUID as an “agent” identifier.


Figure 5. The createGET and getWebRequest classes define the construction of the HTTP request used for command and control communication.

During our analysis, we observed the beacon seen in Figure 6 sent via HTTP from a Kazuar sample to its C2 server. The initial HTTP beacon shows the base64 encoded AuthToken value within the Cookie field that we believe the C2 server uses to uniquely identify and track individual compromised hosts.


Figure 6.  Wireshark snippet of a fully constructed HTTP GET request which shows the base64 encoded GUID within the Cookie header.

Kazuar will read the response from the C2 server and attempt to parse the response as XML formatted data. The XML formatted data will contain what Kazuar refers to as a “task”, which is comprised of an action identifier and specific arguments for each action. Figure 7 below shows the code responsible for receiving the response to the HTTP request and using a long integer stored in the “num” variable as the action identifier.


The response parser listens for new tasks to be received from the command and control server.

The action identifier is directly related to the command which the actor wishes to run on the compromised system. Surprisingly, Kazuar also contains methods for each command to equate the action identifier to a string that describes the command, which makes determining the purpose of each command much easier. Table 2 shows a list of available commands within Kazuar, specifically each action identifier, command string and a description.

Action ID Commands Description
1 log Logs a specified debug message
2 get Upload files from a specified directory. It appears the actor can specify which files to upload based on their modified, accessed and created timestamps as well.
3 put Writes provided data (referred to as ‘payload’) to a specified file on the system.
4 cmd Executes a specified command and writes the output to a temporary file. The temporary file is uploaded to the C2 server
5 sleep Trojan sleeps for a specified time
6 upgrade Upgrades the Trojan by changing the current executable’s file extension to “.old” and writing a newly provided executable in its place
7 scrshot Takes a screenshot of the entire visible screen. The screenshot is saved to a specified filename or using a filename with the following format: [year]-[month]-[day]-[hour]-[minute]-[second]-[milisecond].jpg. The file is uploaded to the C2 server
8 camshot Creates a Window called “WebCapt” to capture an image from an attached webcam, which it copies to the clipboard and writes to a specified file or a file following the same format from the “scrshot” command. The file is uploaded to the C2 server
9 uuid Sets the unique agent identifier by providing a specific GUID
10 interval Sets the transport intervals, specifically the minimum and maximum time intervals between C2 communications.
11 server Sets the C2 servers by providing a list of URLs
12 transport Sets the transport processes by providing a list of processes that Kazuar will inject its code and execute within.
13 autorun Sets the autorun type as discussed earlier in this blog. Kazuar will accept the following strings for this command: DISABLED, WINLOGON, POLICIES, HKCURUN, RUNONCE, LOADKEY, STARTUP
14 remote Sets a remote type. We are only aware of one remote type that instructs Kazuar to act as an HTTP server and allow the threat actor to interact with the compromised system via inbound HTTP requests.
15 info Gathers system information, specifically information referred to as: Agent information, System information, User information, Local groups and members, Installed software, Special folders, Environment variables, Network adapters, Active network connections, Logical drives, Running processes and Opened windows
16 copy Copies a specified file to a specified location. Also allows the C2 to supply a flag to overwrite the destination file if it already exists.
17 move Moves a specified file to a specified location. Also allows the C2 to supply a flag to delete the destination file if it exists.
18 remove Deletes a specified file. Allows the C2 to supply a flag to securely delete a file by overwriting the file with random data before deleting the file.
19 finddir Find a specified directory and list its files, including the created and modified timestamps, the size and file path for each of the files within the directory.
20 kill Kills a process by name or by process identifier (PID)
21 tasklisk List running processes. Uses a WMI query of “select * from Win32_Process” for a Windows system, but can also running “ps -eo comm,pid,ppid,user,start,tty,args” to obtain running processes from a Unix system.
22 suicide We believe this command is meant to uninstall the Trojan, but it is not currently implemented in the known samples.
23 plugin Installing plugin by loading a provided Assembly, saving it to a file whose name is the MD5 hash of the Assembly’s name and calling a method called “Start”.
24 plugout Removes a plugin based on the Assembly’s name.
25 pluglist Gets a list of plugins and if they are “working” or “stopped”
26 run Runs a specified executable with supplied arguments and saves its output to a temporary file. The temporary file is up loaded to the C2 server.

Table 2: Kazuar’s command handler, including action identifier, command string and description.


As can be seen from the Table 2 above, Kazuar has an extensive command set, many of which are similar in functionality as other backdoor Trojans. However, a few commands specific to Kazuar appear to be unique and are worth further discussion.

First, several of these commands contain checks to determine the environment in order to use appropriate paths or commands. The ‘tasklist’ command will use a WMI query or the “ps” command, which allows Kazuar to obtain running processes from both Windows and Unix systems. Also, Kazuar’s ‘cmd’ command will run commands using “cmd.exe” for Windows systems and “/bin/bash” for Unix systems. These two commands provide evidence that the authors of Kazuar intended to use this malware as a cross-platform tool to target both Windows and Unix systems.

Kazuar contains three commands related to plugins: plugin, plugout and pluglist. These three commands allow an actor to administer a framework that allows Kazuar to use additional plugins. This plugin framework provides Kazuar potentially endless functionality, as its operators can provide additional .NET applications that Kazuar can load and execute.

Kazuar’s Remote API:

While many backdoor Trojans have extensive command handlers and plugin frameworks, Kazuar’s ‘remote’ command provides a functionality that is rarely seen in backdoors used in espionage campaigns. This command instructs the Trojan to start a thread to listen for inbound HTTP requests, which effectively turns Kazuar into a webserver. This functionality provides an API for the Trojan to run commands on the compromised system. Figure 8 shows the code within Kazuar that provides this functionality.


Figure 8 HTTP method handler used by Kazuar to provide threat actors with API access

To initiate this functionality, the actor will issue the ‘remote’ command and provide a list of URI prefixes that Kazuar’s HTTP listener will process and respond to. The URI prefix supplied by the actor would be added to the “Prefixes” property of the HttpListener class, which requires a schema, a host, an optional port and optional path. The actor would then issue HTTP requests to URLs that match these URI prefixes using specific methods, specifically OPTIONS, POST, GET and PUT methods to interact with the compromised system using Kazuar’s command set seen in Table 3.

This functionality flips the communication flow between the Trojan and the C2 server. Instead of the Trojan initiating communications with its C2 server, the C2 server sends requests directly to the Trojan. This communications flow is important if the compromised system is a remotely accessible server that may raise flags when initiating outbound requests. Also, by creating this type of API access, the threat actors could use one accessible server as a single point to dump data to and exfiltrate data from.

HTTP Method Description of Functionality
OPTIONS No functionality, just responds with an HTTP “OK” status
POST Actor provides XML formatted data that Kazuar will use to create a new task. Uses the exact same method (‘readResponse0’ seen in Figure 7) to parse the XML data obtained in the initial C2 communications channel discussed earlier. Kazuar writes the results of the task to a log file that it references as “res” within a folder referenced as “tsk”.
GET Provides the contents of the results of the previous task created via the HTTP POST request that is stored in the “res” file.
PUT Actor provides XML formatted data that Kazuar will use to create a new task. This method is similar to the POST method, however, instead of saving the results of the command to a “res” file it responds to the HTTP PUT request with the results of the command.

Table 3 HTTP methods and the functionality they provide in Kazuar’s API

This functionality flips the communication flow between the Trojan and the C2 server. Instead of the Trojan initiating communications with its C2 server, the C2 server sends requests directly to the Trojan. This communications flow is important if the compromised system is a remotely accessible server that may raise flags when initiating outbound requests. Also, by creating this type of API access, the threat actors could use one accessible server as a single point to dump data to and exfiltrate data from.


While yet another fully featured backdoor alone is not particularly novel, the existence of a code path for Unix, combined with the portability of .NET Framework code makes the Kazuar Trojan an interesting tool to keep an eye on. Another interesting portion of this malware is its remote API that allows actors to issue commands to the compromised system via inbound HTTP requests. Based on our analysis, we believe that threat actors may compile Windows and Unix based payloads using the same code to deploy Kazuar against both platforms. Palo Alto Networks AutoFocus subscribers can explore additional samples using the Kazuar AutoFocus tag.

Indicators of Compromise:










File Activity:



%USERPROFILE%\Start Menu\Programs\Startup\*.lnk

RSA Keys:



Decrypted Log and Error Messages:

‘{0}’ autorun algorithm is not supported!

‘{0}’ request method isn’t supported.

Accessed date mismatch in get command!

Accessed date mismatch in list command!

Action with identifier {0} is not implemented.

Autorun command requeres autorun type to be set!

Autorun failed due to {0}

Cmd command requires actual commands list!

Commiting suicide…

Control server address ‘{0}’ is invalid.

Copy command requires destination path!

Copy command requires source path!

Copying file from {0} to {1}…

Created date mismatch in get command!

Created date mismatch in list command!

Directory listing for {0}

Executing command with {0}…

Failed to create agent due to {0}

Failed to create channel due to {0}

Failed to create injector due to {0}

Fatal failure due to {0}

Getting file query {0}…

Getting system information…

Going to sleep for {0}…

Got ‘{0}’ command from {1}.

Got new ‘{0}’ command.

Got new task #{0} from {1}.

HTTP listening isn’t supported.

IPC channel is not ready.

Injected into explorer.

Injected into {0} [{1}].

Injecting into explorer…

Injecting into {0} [{1}]…

Injection failed due to {0}

Installing plugin…

Invalid FTP server status ({0}).

Invalid last contact time.

Invalid or unknown action format ({0})!

Invalid sender interval.

Kazuar’s {0} started in process {1} [{2}] as user {3}/{4}.

Killing processes…

List command requires file query string!


Listing plugins…

Listing processes…

Max interval value is less than min value!

Max interval value is more than supported!

Min interval value is less than supported!

Modified date mismatch in get command!

Modified date mismatch in list command!

Move command requires destination path!

Move command requires source path!

Moving file from {0} to {1}…

Mozilla/5.0 (Windows NT {0}.{1}; rv:22.0) Gecko/20130405 Firefox/23.0

Mozilla/5.0 (X11; {0} {1}; rv:24.0) Gecko/20100101 Firefox/24.0

New plugin {0} was installed.

No servers available now.

Plugin command requires payload!

Plugin installed.

Plugin removed.

Plugin {0} was removed.

Plugin {0} was started.

Plugout command requires plugin name string!

Proc kill command requires name or pid to be set!

Process {0} [{1}] exited with {2} code.

Process {0} [{1}] impersonated.

Put command requires correct file path!

Put command requires payload!

Putting file to {0}…

Remote control failed due to {0}

Remote failed due to {0}

Remote iteration failed due to {0}

Remote request from {0} failed due to {1}

Remove command requires file path!

Removing file {0}…

Removing plugin…

Request was sent to {0}.

Result #{0} was sent to {1}.

Result #{0} was taken by {1}.

Run command requires executable path!

Run-time error {0}:{1:X8}.

Run-time error {0}:{1}.

Scheme ‘{0}’ is not supported!

Searching file query {0}…

Send iteration failed due to {0}

Sending request to {0}…

Sending result #{0} to {1}…

Server command requires at least one server!

Setting agent id to {0}…

Setting autorun type to {0}…

Setting remote type to {0}…

Setting transport interval to [{0} – {1}]…

Setting transport processes:

Setting transport servers:

Shellcode error {0:X16}.

Sleep interval is longer than supported!

Solving task #{0}…

Startup path is empty.

Taking screen shot…

Taking webcam shot…

Task #{0} execution finished.

Task #{0} execution started:

Task #{0} failed due to {1}

Task #{0} solved.

Transport command requires at least one process name!

Transport process name ‘{0}’ is invalid.

Transport processes

Unable to create capture window.

Unable to delete task #{0} file due to {1}

Unable to execute command due to {0}

Unable to execute task #{0} due to {1}

Unable to get last contact time due to {0}

Unable to get task from {0} due to {1}

Unable to impersonate {0} [{1}] due to {2}

Unable to return logs due to {0}

Unable to send result #{0} to {1} due to {2}

Unable to start plugin {0} due to {1}

Unable to stop plugin {0} due to {1}

Unable to store agent id due to {0}

Unable to store autorun type due to {0}

Unable to store interval due to {0}

Unable to store remote type due to {0}

Unable to store servers due to {0}

Unable to store transports due to {0}

Unhandled exception {0}

Upgrade command requires payload!

Upgrading agent…

Using default agent id due to {0}

Using default autorun type due to {0}

Using default interval due to {0}

Using default remote type due to {0}

Using default servers due to {0}

Using default transports due to {0}

Uuid command requires identifier!

Waiting for shellcode failed.

Waiting for window ‘{0}’ failed.

explorer.exe, {0}

ERROR: {0}

Plugin {0}

{0} doesn’t exist!

{0} was skipped.

proc – {0} [{1}]

time – {0}

user – {0}/{1} ({2})