Casper - new cyber espionage malware
In March 2014, the French edition of Le Monde published a study, according to which French intelligence agencies are suspected of developing and using sophisticated malware for cyber espionage. Initially, this story was based on documents from a runaway NSA employee Edward Snowden, whom he shared with journalists from the German publication Der Spiegel in January 2015.
An initial investigation of this malware was carried out by the 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 devoted to the analysis of this malicious program [ 1 ] [ 2 ].
')
Another study was published by one of the researchers of the anti-virus company G DATA. In our study, we publish an analysis of another similar malware that was created by the same organization that was behind the development of Babar. This malware is called Casper.
Casper himself was used against the Syrian government agencies in April 2014. To install it, attackers used 0day exploits for the Adobe Flash Player software. The exploits were posted on a website owned by the Syrian government. Casper is a well-developed tool for conducting intelligence operations, which can go unnoticed on an infected computer for a long time. It also contains code to counteract AV products from various vendors.
We found two malware samples that were packaged by different packers. The first sample is a dropper and dumps another executable file (core) to disk, which will be loaded into 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 file 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 section of memory 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.
Dropper executable code starts using the XML configuration file by analyzing the STRATEGY tag, which defines a section of the configuration file. This tag sets the behavior mode for a malicious program, depending on which anti-virus product is installed in the system. The list of anti-virus products launched in the system, the dropper receives using the “SELECT * FROM AntiVirusProduct” query using WMI , then the product name is extracted from the “displayName” field. In this section of the configuration file, there may also be a list of anti-virus products, each of which is identified by an AV tag. In this case, the malware can take a series of actions to disable this or that product.
If there is no list of anti-virus products in the STRATEGY section, the default actions that are specified as an argument to the STRATEGY tag are applied to the anti-virus product detected in the system. In addition, the behavior policy of malware for anti-virus products can be set in a separate configuration file called “strategy.xml”.
As already mentioned, the behavior of the dropper, as well as the payload, is determined by the parameters that are specified in the configuration file. Some of the tags or sections describe how exactly the executable code of the malicious program must perform the appropriate actions and in what cases. The table below shows examples of such parameters.
The range of possibilities offered by the STRATEGY section shows that Casper conducted an in-depth study of the behavior of various antivirus products. In the presented screenshot of the configuration file, you can see that the INJECTION parameter for all AV tags is set to FALSE, and for the whole section, which is set by the STRATEGY tag to TRUE. This means that for all antivirus products encountered in the system except these four, the executable code will be introduced into their processes. 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 a malicious program into the system if these anti-virus products are present there.
According to the list of anti-virus 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 the malicious code. It allows malware authors to fix the versions of antivirus products they need. We very rarely observed such an accuracy of the implementation of anti-virus bypass mechanisms by malicious code.
In the case when the ESCAPE parameter is set to NO, i.e., the dropper can continue its work normally, it will proceed to the analysis of 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 accompanied by the name parameter, which is located in the Windows registry. Obviously, the authors wanted to disguise the autoload of the malware module by giving it the name “Audio Interface Device Manager”. The mechanism for deleting an existing copy of a malicious program from the system consists of two stages. Each stage cleans the corresponding autoload mechanism.
Further, the dropper installs the payload into the system (section INSTALL). 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 with one or two methods of installing the payload into the system. In the case of Windows 7+, malware survival 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 a parameter contains an argument that can be passed to the payload installed in the system. The exact value of this argument is extremely important for proper operation of the payload. The argument passed in this way is used to find the functions of dynamic libraries needed by the malicious program in memory. In the event that this value is erroneous, the payload will not be able to properly execute its code.
Before completing its execution, the dropper deletes itself from the system using the method specified in the AUTODEL parameter. At this point, the payload is not yet running on the system; this will be done after the next reboot.
Payload
The execution of the Casper payload as well as its dropper is based on an XML configuration file, which is deciphered at the initial stage.
Fig. Payload configuration file
The configuration file starts with a timestamp that corresponds to Monday, April 7th, 2014 at 9:27:05 GMT GMT, therefore, the compile time mark of the executable file of the malicious program indicated at the beginning of our report is most likely a fake and not true.
A PARAM tag set specifies instructions to executable payload code.
The payload executable code then generates the unique identifier (ID) of the infected computer and inserts it at the end of the configuration file with the UID tag. After this, the configuration file is encrypted using the RC4 algorithm and stored in the system registry section.
Some features of the configuration file are not used by the executable code of the payload of those Casper files that we observed. This applies to the parameter TIMETOLIVE, 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 waiting time that the payload code must withstand before executing its basic functions. The payload configuration file contains the STRATEGY section similar to the one that was present in the dropper configuration file.
Interaction with the C & C server
The payload can interact with its C & C server. The instructions from the server can come in XML format, as shown below.
The SYSINFO team instructs the bot to send system information to a remote server. Information is sent in the form of a report that contains several sections. An example of the report is shown below in the screenshot.
Fig. Information about the system sent by the bot to a remote server.
Obviously, the section names in this report do not need clarification. The report itself is generated by the 4.4.1 bot. The report is saved to the “perfaudio.dat” file and then encrypted with the base64 algorithm, after which its contents are sent to a remote C & C server in the body of the HTTP POST request.
The C & C server request is also provided with a cookie named PREF, to which the infected computer's UID is attached, the configuration file ID, the bot version, and the “R” symbol, all of which are encrypted using the base-64 algorithm. Another character can act as a symbol - “G”. Analysis of the executable file showed that the server in this case can send the image file in PNG format to the bot. 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 the instructions from it will be executed by the bot.
In addition to the “SYSINFO” command, Casper can interpret the “COMMAND” tags with the following values.
The malicious program can also process tags that indicate to the bot the executable file to be executed.
The best way to establish a link between the Babar, Bunny and Casper malware is to detect unusual sections of executable code and the algorithms they use. For comparison, you can enable another malicious program, so-called. NBOT (aka TFC). The presence of common links with NBOT and the malware listed above was identified by a Marion Marschalek researcher in her report on Babar. Below is a list of such common features of these malicious programs.
It should be noted that none of these signs 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 .
Conclusion
Our telemetry data shows that all the alleged victims of these cyber attacks were located in Syria, and besides that, they were visitors of the jpic.gov.sy website. This site was allegedly compromised and users were redirected from it to the exploit kit page. In fact, users could be redirected to install malware from other places as well, such as a phishing email. However, it is precisely known that the exploits, executable files of Casper, as well as the C & C component, were located on this legitimate server (jpic.gov.sy).
It can be assumed that the mentioned website or its server 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 intruders themselves: first, placing the 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 a stable infection of users. Secondly, such a situation may be misleading the efforts of the law enforcement agencies themselves, who are interested in finding the source of the cyber attack.
We are sure that the same organization or hacker group is behind Bunny, Babar, and Casper. In a detailed analysis of the Babar malware, which was published at the CSEC presentation, it was stated that this group is not new to the development of cyber espionage tools. The use of zero-day exploits is another indicator that the authors of Casper belong to a highly professional group. Finally, the specific thrust 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 point to authors in a particular country. In particular, we did not find any signs of its French origin, as was found by the CSEC in the case of Babar.
An initial investigation of this malware was carried out by the 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 devoted to the analysis of this malicious program [ 1 ] [ 2 ].
')
Another study was published by one of the researchers of the anti-virus company G DATA. In our study, we publish an analysis of another similar malware that was created by the same organization that was behind the development of Babar. This malware is called Casper.
Casper himself was used against the Syrian government agencies in April 2014. To install it, attackers used 0day exploits for the Adobe Flash Player software. The exploits were posted on a website owned by the Syrian government. Casper is a well-developed tool for conducting intelligence operations, which can go unnoticed on an infected computer for a long time. It also contains code to counteract AV products from various vendors.
We found two malware samples that were packaged by different packers. The first sample is a dropper and dumps another executable file (core) to disk, which will be loaded into 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 file 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 section of memory 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.
Dropper executable code starts using the XML configuration file by analyzing the STRATEGY tag, which defines a section of the configuration file. This tag sets the behavior mode for a malicious program, depending on which anti-virus product is installed in the system. The list of anti-virus products launched in the system, the dropper receives using the “SELECT * FROM AntiVirusProduct” query using WMI , then the product name is extracted from the “displayName” field. In this section of the configuration file, there may also be a list of anti-virus products, each of which is identified by an AV tag. In this case, the malware can take a series of actions to disable this or that product.
If there is no list of anti-virus products in the STRATEGY section, the default actions that are specified as an argument to the STRATEGY tag are applied to the anti-virus product detected in the system. In addition, the behavior policy of malware for anti-virus products can be set in a separate configuration file called “strategy.xml”.
As already mentioned, the behavior of the dropper, as well as the payload, is determined by the parameters that are specified in the configuration file. Some of the tags or sections describe how exactly the executable code of the malicious program must perform the appropriate actions and in what cases. The table below shows examples of such parameters.
The range of possibilities offered by the STRATEGY section shows that Casper conducted an in-depth study of the behavior of various antivirus products. In the presented screenshot of the configuration file, you can see that the INJECTION parameter for all AV tags is set to FALSE, and for the whole section, which is set by the STRATEGY tag to TRUE. This means that for all antivirus products encountered in the system except these four, the executable code will be introduced into their processes. 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 a malicious program into the system if these anti-virus products are present there.
According to the list of anti-virus 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 the malicious code. It allows malware authors to fix the versions of antivirus products they need. We very rarely observed such an accuracy of the implementation of anti-virus bypass mechanisms by malicious code.
In the case when the ESCAPE parameter is set to NO, i.e., the dropper can continue its work normally, it will proceed to the analysis of 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 accompanied by the name parameter, which is located in the Windows registry. Obviously, the authors wanted to disguise the autoload of the malware module by giving it the name “Audio Interface Device Manager”. The mechanism for deleting an existing copy of a malicious program from the system consists of two stages. Each stage cleans the corresponding autoload mechanism.
- In the presence of a scheduled task (scheduled task), it is removed from the system.
- If a malware entry is present in the registry, it is deleted.
Further, the dropper installs the payload into the system (section INSTALL). 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 with one or two methods of installing the payload into the system. In the case of Windows 7+, malware survival 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 a parameter contains an argument that can be passed to the payload installed in the system. The exact value of this argument is extremely important for proper operation of the payload. The argument passed in this way is used to find the functions of dynamic libraries needed by the malicious program in memory. In the event that this value is erroneous, the payload will not be able to properly execute its code.
Before completing its execution, the dropper deletes itself from the system using the method specified in the AUTODEL parameter. At this point, the payload is not yet running on the system; this will be done after the next reboot.
Payload
The execution of the Casper payload as well as its dropper is based on an XML configuration file, which is deciphered at the initial stage.
Fig. Payload configuration file
The configuration file starts with a timestamp that corresponds to Monday, April 7th, 2014 at 9:27:05 GMT GMT, therefore, the compile time mark of the executable file of the malicious program indicated at the beginning of our report is most likely a fake and not true.
A PARAM tag set specifies instructions to executable payload code.
The payload executable code then generates the unique identifier (ID) of the infected computer and inserts it at the end of the configuration file with the UID tag. After this, the configuration file is encrypted using the RC4 algorithm and stored in the system registry section.
Some features of the configuration file are not used by the executable code of the payload of those Casper files that we observed. This applies to the parameter TIMETOLIVE, 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 waiting time that the payload code must withstand before executing its basic functions. The payload configuration file contains the STRATEGY section similar to the one that was present in the dropper configuration file.
Interaction with the C & C server
The payload can interact with its C & C server. The instructions from the server can come in XML format, as shown below.
The SYSINFO team instructs the bot to send system information to a remote server. Information is sent in the form of a report that contains several sections. An example of the report is shown below in the screenshot.
Fig. Information about the system sent by the bot to a remote server.
Obviously, the section names in this report do not need clarification. The report itself is generated by the 4.4.1 bot. The report is saved to the “perfaudio.dat” file and then encrypted with the base64 algorithm, after which its contents are sent to a remote C & C server in the body of the HTTP POST request.
The C & C server request is also provided with a cookie named PREF, to which the infected computer's UID is attached, the configuration file ID, the bot version, and the “R” symbol, all of which are encrypted using the base-64 algorithm. Another character can act as a symbol - “G”. Analysis of the executable file showed that the server in this case can send the image file in PNG format to the bot. 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 the instructions from it will be executed by the bot.
In addition to the “SYSINFO” command, Casper can interpret the “COMMAND” tags with the following values.
- EXEC, used to execute another program on the computer on a local path.
- SYSTEM, used to execute instructions in the Windows command line.
The malicious program can also process tags that indicate to the bot the executable file to be executed.
The best way to establish a link between the Babar, Bunny and Casper malware is to detect unusual sections of executable code and the algorithms they use. For comparison, you can enable another malicious program, so-called. NBOT (aka TFC). The presence of common links with NBOT and the malware listed above was identified by a Marion Marschalek researcher in her report on Babar. Below is a list of such common features of these malicious programs.
- 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 mechanism is not used anywhere in Casper.
- Casper uses special delimiters when organizing its HTTP requests using a special format string, the values ​​for which are generated by the well-known API function GetTickCount . A similar code is also present in the NBOT samples, as shown below in the screenshots.
- 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 instances of NBOT, we may find a similar command syntax.
cmd.exe / C FOR / L %% i IN (1.1,% d) DO IF EXIST “% s” (DEL “% s” & PING 127.0.0.1 -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 the 8th slide in the CSEC presentation ).
It should be noted that none of these signs 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 .
Conclusion
Our telemetry data shows that all the alleged victims of these cyber attacks were located in Syria, and besides that, they were visitors of the jpic.gov.sy website. This site was allegedly compromised and users were redirected from it to the exploit kit page. In fact, users could be redirected to install malware from other places as well, such as a phishing email. However, it is precisely known that the exploits, executable files of Casper, as well as the C & C component, were located on this legitimate server (jpic.gov.sy).
It can be assumed that the mentioned website or its server 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 intruders themselves: first, placing the 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 a stable infection of users. Secondly, such a situation may be misleading the efforts of the law enforcement agencies themselves, who are interested in finding the source of the cyber attack.
We are sure that the same organization or hacker group is behind Bunny, Babar, and Casper. In a detailed analysis of the Babar malware, which was published at the CSEC presentation, it was stated that this group is not new to the development of cyber espionage tools. The use of zero-day exploits is another indicator that the authors of Casper belong to a highly professional group. Finally, the specific thrust 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 point to authors in a particular country. In particular, we did not find any signs of its French origin, as was found by the CSEC in the case of Babar.
Source: https://habr.com/ru/post/252577/
All Articles