Casper - new cyber espionage malware

    In March 2014, the French publication Le Monde published a study according to which French secret services are suspected of developing and using sophisticated malware for cyber espionage. Initially, this story was based on documents from a fugitive NSA officer Edward Snowden, whom he shared with journalists of the German publication Der Spiegel in January 2015.

    An initial investigation of this malware was carried out by Communications Security Establishment Canada (CSEC), in which this malware was named Babar. After that, several malware researchers also worked on its analysis. One of them was Marion Marschalek (Cyphort), which published two reports on the analysis of this malicious program [ 1 ] [ 2 ].

    Another study was published by one of the researchers of the antivirus company G DATA. In our research, we publish an analysis of another similar malicious program that was created by the same organization that was behind the development of Babar. This malware is called Casper.

    Casper itself was used against Syrian government agencies in April 2014. To install it, attackers used 0day exploits for Adobe Flash Player software. The exploits were posted on a website owned by the Syrian government. Casper is a well-developed reconnaissance tool that can go unnoticed on an infected computer for a long time. It also contains code to counter the AV products of various vendors.

    We found two samples of malware that were packaged by different packers. The first sample is a dropper and flushes another executable file (core) to the disk, which will be loaded in the system after each reboot. The second is a DLL library that loads the core component into memory. In this case, the core component is also a DLL file, and its name is Casper_DLL.dll.

    Dropper The dropper

    executable is called “domcommon.exe” and its compilation date is June 18, 2010. It is likely that this compilation date in the header of the PE file is fake.

    The malicious program has a configuration file in XML format, which is decrypted by the dropper using the RC4 algorithm and a hard-wired 16-byte key. Before decrypting it, the dropper checks the integrity of the memory area that contains the key by calculating the checksum. Such an operation is carried out in order to verify its integrity. The screenshot below shows the decrypted configuration file.

    Fig. Decrypted Casper dropper configuration file.

    The dropper executable starts using the XML configuration file by analyzing the STRATEGY tag, which defines the section of the configuration file. This tag sets the behavior for the malicious program, depending on which anti-virus product is installed on the system. The dropper receives the list of the antivirus products launched in the system using the WMI query “SELECT * FROM AntiVirusProduct”, then the product name is retrieved from the “displayName” field. This section of the configuration file may also contain a list of anti-virus products, each of which is identified by the AV tag. In this case, a malicious program may take a number of actions to disable a product.

    If there is no list of anti-virus products in the STRATEGY section, the default actions that are specified as arguments to the STRATEGY tag are applied to the anti-virus product detected in the system. In addition, the malware behavior policy for anti-virus products can be set in a separate configuration file called “strategy.xml”.

    As already indicated, the behavior of the dropper, as well as the payload, is set by the parameters that are specified in the configuration file. Some of the tags or sections describe in what way the executable code of the malicious program should perform appropriate actions and in what cases. The table below shows examples of such parameters.

    The range of opportunities provided by the STRATEGY section shows that Casper authors conducted an in-depth study of the behavior of various antivirus products. The screenshot of the configuration file shows that the INJECTION parameter for all AV tags is set to FALSE, and for the entire section that is set with the STRATEGY tag to TRUE. This means that for all the antivirus products encountered in the system except these four, the implementation of the executable code in their processes will be carried out. It is interesting to note that for the three antivirus products, the ESCAPE parameter is set to YES. This means that the dropper will simply refuse to install malware into the system if these anti-virus products are present there.

    According to the list of antivirus products listed in the AV tags, we can assume that these are the products that Casper authors expect to find on infected computers. The VERSION parameter, which may be present in the AV tag, is never used in malicious code. It allows malware authors to capture the versions of antivirus products they need. We very rarely observed such accuracy in the implementation of anti-virus software bypass mechanisms by malicious code.

    In the case when the ESCAPE parameter is set to NO, that is, the dropper can continue its work normally, it will proceed to analyze the next set of instructions from the configuration file.

    Fig. Part of the dropper configuration file.

    The first such command tells the malicious code to remove other already installed Casper instances from the system. The UNINSTALL tag is followed by the name parameter, which is located in the Windows registry. Obviously, the authors wanted to mask the startup of the malware module by giving it the name “Audio Interface Device Manager”. The mechanism for removing an existing copy of a malicious program from the system consists of two stages. Each stage cleans up the corresponding startup mechanism.

    • If a scheduled task is present, it is deleted from the system.
    • If a malicious program entry is present in the registry, it is deleted.

    Next, the dropper installs the payload into the system (INSTALL section). This section regulates two versions of the payload, one for 32-bit systems (x86 tag) and the other for 64-bit systems (x64 tag). The INSTALL section will be used by one or two methods of setting the payload to the system. In the case of Windows 7+, the survival of the malicious program is ensured by the scheduled task mechanism, otherwise the well-known registry key is used.

    HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Run

    The INSTALL tag as an argument contains an argument that can be passed to the payload being installed on the system. The exact meaning of this argument is critical to the proper operation of the payload. The argument passed in this way is used to find the dynamic library functions necessary for the malicious program in memory. In the event that this value is erroneous, the payload will not be able to execute its code normally.

    Before completing its execution, the dropper removes itself from the system using the method specified in the AUTODEL parameter. At this point, the payload is not yet running on the system, it will be done after the next reboot.


    Casper payload execution, like its dropper, is based on the XML configuration file, which is decrypted at the initial stage.

    Fig. Payload configuration file.

    The configuration file starts with a timestamp that corresponds to Monday, April 7, 2014, 9:27:05 p.m. GMT, therefore, the time stamp at the beginning of our report for compiling the executable file of the malicious program is most likely fake and not true.

    The set of PARAM tags indicates instructions to the payload executable code.

    The payload executable code then generates a unique identifier (ID) for the infected computer and inserts it at the end of the configuration file with the UID tag. After that, the configuration file is encrypted using the RC4 algorithm and stored in the registry key.

    Some features of the configuration file are not used by the payload executable code of those Casper files that we observed. This applies to the TIMETOLIVE parameter, which sets the so-called Casper's “lifetime” in the system, after which he will remove himself from there. The DELAYED_START parameter specifies the wait time that the payload code must withstand before executing its basic functions. The payload configuration file contains a STRATEGY section similar to the one present in the dropper configuration file.

    Interaction with a C&C server

    A payload can interact with its C&C server. Instructions from the server may come in XML format, as shown below.

    The SYSINFO command instructs the bot to send system information to a remote server. Information is sent in the form of a report that contains several sections. A sample report is shown below in the screenshot.

    Fig. System information sent by the bot to the remote server.

    Obviously, the section names in this report do not need to be explained. The report itself is generated by the bot version 4.4.1. The report is saved to the “perfaudio.dat” file and then encrypted with the base64 algorithm, after which its contents are sent to the remote C & C server in the body of the POST request for the HTTP protocol.

    The C & C server request is also provided with a cookie with the name PREF, to which the UID of the infected computer, the configuration file ID, the bot version, and the “R” symbol are attached, all of which are encrypted with the base-64 algorithm. The symbol may also be another - “G”. Analysis of the executable file showed that the server in this case can send the bot an image file in PNG format. This image file has the usual PNG format, but instead of the image contains an XML configuration file. This file will be extracted from there and instructions from it will be executed by the bot.

    In addition to the SYSINFO command, Casper can interpret COMMAND tags with the following meanings.

    • EXEC, used to execute another program on a computer on a local path.
    • SYSTEM, used to execute instructions on the Windows command line.

    A malicious program may also process tags that indicate to the bot the executable file for execution.

    The best way to establish a connection between the malware Babar, Bunny and Casper is to detect unusual sections of the executable code and the algorithms they use. For comparison, you can include another malicious program, the so-called. NBOT (aka TFC). The presence of common connections between NBOT and the above malware was established by researcher Marion Marschalek in her report on Babar. The following is a list of these common features of these malware.

    • Casper hides calls to Windows API functions using special hashes of the names of these functions. The hash calculation algorithm is a combination of the ROL algorithm and the XOR algorithm. At the same time, NBOT uses the same algorithm for this purpose. Babar uses a similar approach, but the calculation algorithm is different.
    • Casper receives information about running anti-virus products in the same way (WMI API) as Bunny, Babar, NBOT. All these malicious programs calculate the SHA-256 hash from the first word in the name of the anti-virus product, although this is exactly the mechanism that Casper does not use anywhere.
    • Casper uses special delimiters when organizing its HTTP requests using a special format string, the values ​​for which are generated by GetTickCount, a well-known API . A similar code is present in NBOT samples, as shown in the screenshots below.

    • Casper removes the dropper from the system by executing a Windows command that matches the following pattern.

      cmd.exe / C FOR / L %% i IN (1,1,% d) DO IF EXIST “% hs” (DEL “% hs” & SYSTEMINFO) ELSE EXIT

      In some NBOT instances, we can find a similar command syntax.

      cmd.exe / C FOR / L %% i IN (1,1,% d) DO IF EXIST “% s” (DEL “% s” & PING -n 3) ELSE EXIT
    • Casper sets the ID parameter to “13001”, while Babar samples set this value to “12075-01”. In addition, one malware detected by CSEC in 2009 uses the same identifier and is set to “08184” (see slide 8 in the CSEC presentation ).

    It should be noted that none of these features is sufficient to make an unambiguous conclusion, at the same time, they allow us to state with a high degree of probability that Bunny, Babar, NBOT, and Casper were developed by one group of persons or organization .


    Our telemetry data shows that all the alleged victims of these cyber attacks were located in Syria, in addition, they were visitors to the website This site was allegedly compromised and users were redirected from it to the exploit kit page. In fact, users could be redirected to the installation of malware from other places, such as a phishing message. However, it is well known that the exploits, Casper executable files, as well as the C&C component, were located on this legitimate server (

    It can be assumed that the website or server mentioned was hacked in order to place malicious content there (the so-called storage area). Such an attack model can have at least two advantages for the attackers themselves: firstly, placing files on the Syrian server makes it easier to access on the territory of Syria itself, because in this country there were disconnections from the Internet, and the attackers were interested in stable infection of users. Secondly, such a situation may mislead the efforts of law enforcement agencies themselves, which are interested in detecting the source of a cyber attack.

    We are sure that the same organization or hacker group is behind Bunny, Babar, and Casper. A detailed analysis of the Babar malware, which was published at the CSEC presentation, indicated that this group is not new to cyber espionage tools. The use of zero-day exploits is another indicator that Casper authors belong to a highly professional group. Finally, the specific focus of the attack on Syrian citizens shows the geopolitical interest of the attackers.

    However, we did not find any evidence in the Casper files to indicate authors in a particular country. In particular, we did not find any signs of her French origin, as was found by CSEC in the case of Babar.

    Also popular now: