Win32 / Syndicasec.A backdoor used in cyber espionage operation
We recently encountered an interesting pattern of malicious code that ESET detects as Win32 / Syndicasec.A . He drew attention for a number of the following reasons:
We conducted a detailed study of this backdoor and found out the details of its installation on a compromised computer, the mechanisms it uses to maintain its presence, as well as the details of interaction with the C & C server.
Establish and maintain presence
')
An exploit is used to install the Win32 / Syndicasec malware. Despite the fact that operations of blocking the actions of this exploit by our anti-virus products were recorded, we could not get it all, so we are not sure which particular exploit was used for the attack. Next, the two-step backdoor installation process begins.
At the first stage, the dropper performs some preparatory actions. Checks for the existence of the% SYSTEM32% \ sysprep.exe file. If it is present, the malicious code copies the extracted .cab file to the% TEMP% directory. Further, the contents of this archive will be copied to the% SYSTEM32% \ cryptbase.dll file using the Windows Update Standalone Installer tool (wusa.exe). To do this, use the command shown below.
The .cab file itself is stored in a dropper in open form, with the exception that the archive signature is missing - the first few bytes. These bytes will be added to the memory buffer before it is written to a file on the disk.
To elevate privileges, the dropper attempts to exploit a vulnerability known as COM Elevation (UAC whitelist). A similar method of elevating privileges in the system was used by the Avatar rootkit dropper, which was reviewed by us.
Inside this library, we found a debug line that gives some insight into the project.
The second stage consists in the execution of another dropper, which is stored in% TEMP% \ gupdate.exe. If the sysprep.exe tool is present in the system, the dropper is launched using this tool. When performing the dropper, the privilege elevation technique is also used by exploiting UAC whitelist. If sysprep is not found on the system, the usual command interpreter cmd.exe is used to execute gupdate.exe.
The gupdate.exe executable is responsible for setting the payload to the system. WMI is used for this. It should be noted that in malware this method is quite rare. This tactic was seen in the Stuxnet worm. You can find a detailed description of it in a document from our colleagues at Trend Micro.
The method of installing a payload using WMI has a number of very useful features from the point of view of an attacker, for example, the malicious code is not obliged to be permanently stored as a file on disk. This approach significantly reduces the chances of detecting malicious activity using tools like Process Explorer.
Installing the payload in the system is as follows. At the first stage, the Javascript code fragment is decrypted in the gupdate.exe dropper using normal XOR. An example of this code is presented below in the screenshot.
Then it creates its own WMI classes.
1. Class __TimerInstruction
The malicious code creates a class __TimerInstruction to set an event called “ProbeScriptInit” to the alarm state every 60,000 milliseconds.
2. Class __EventFilter
This class is responsible for the logical combination of a special timer with the malicious code contained in __EventConsumer .
3. __EventConsumer
This class contains malicious code that is executed each time the event is set with the __TimerInstruction code.
The above objects are located in the root \ subscription namespace, which ensures their sufficient secrecy.
Backdoor capabilities and networking
Consider a malicious script that is contained in the __EventConsumer object. The code from this script is quite simple to analyze. It can be seen that it contains URLs that are hard-wired into the code, which are chosen arbitrarily, and are then used to work with the command C & C server through the usual GET HTTP protocol request. We call these addresses: first-level URLs (Stage One URLs). In fact, all of these hard-coded addresses lead to fake blogs on the web pages, where RSS feeds of second-level addresses are used to communicate with C & C servers. The screenshot below shows an example of one of these blogs:
The key element in this RSS feed is a tag that contains an encrypted string between the two delimiters '@'.
The screenshot below shows the script code, in which you can see which procedure is used to decrypt this line.
As a result of the line decryption, another address is obtained, which is called the second level URL (Stage Two URL). This address will be used for actual communication with the command C & C server.
The initial message is sent to the second level URL using the HTTP protocol POST request and contains some basic information about the infected computer. The response to this message is an HTML container div, which contains one or more commands.
Static analysis shows that the received command buffer includes an obfuscated Javascript script that, by means of eval () transformations, extracts another script from itself.
Observed activity
In parallel with the analysis of the code, we tracked the behavior of a special test computer that was infected using Win32 / Syndicasec . After the first few days of monitoring, teams from C & C were recorded. According to the observed interaction of the bot with C & C, it is obvious that this interaction is not automatic, but is controlled by the person behind the bots control console. We came to this conclusion, because every day a different number of commands were sent, sent at irregular intervals.
Below is a screenshot of a fragment of one of the first sessions of bot interaction with a C & C server. If you pay attention to the time stamps, you will find that all commands have been received for more than 30 minutes. It should be noted that each command includes Javascript scripts required for execution. For brevity, we have included the full code for only some functions. Teams with identical time stamps were received in one command buffer.
It can be stated that the operator was viewing the file system on the infected machine, as well as network settings, mapped drives and running programs.
The next day, the operator used another set of commands to collect data about the infected system.
In this session, the operator used similar commands to accomplish similar goals, but they were made somewhat differently. This suggests that in this case we were dealing with a different operator, different from the first one. You can note, for example, the following obvious typo or error in the following line:
ExecuteCommand ('dir c: \\ dir c:');
Second level URL addresses remained unchanged until 2013-04-22. After that a new domain netfortibt.info was added. For information about it, see the next section.
Malicious code history
We found one of the versions of the main malicious script, which dates from July 2010. This script has been uploaded to one of the online Javascript analyzers. The screenshot below shows the differences in the first lines of the script code for the two versions: 0.5.2 and 1.2.0.
By further analyzing the differences between these two versions, we can see the encrypted data in the body of the container title, which refers to the RSS feed and has not been changed in the newer version. On the other hand, it is clear that in the older version, the C & C server did not apply encryption to the commands sent by the bots, but sent them in clear text. The commands were encrypted already in version 1.2.0 of the main script (see the circleDecode () function)
We can see that version 0.5.2 of the script makes calls to the WMI API functions necessary for registering objects in the root \ subscription namespace. This scheme is different from the one used in the newer version 1.2.0, in which this operation depends on the dropper for making WMI calls.
The old version of the script contains only one hard-wired first-level URL, which was still active at the time of writing this analysis. Below is the webpage of this URL.
You can see that only 25 users have visited this page since the date of its publication in September 2010. The decrypted contents of the container title show the inactive second-level URL (hxxp: //.hostaim.com/summer/ieupdate.php).
Another script was found using the same Javascript analyzer. We can see the dialogue between the infected host and the command C & C server starting from 2012. The query line shows that the script version 1.0.1 is running on the infected host.
The above information quite clearly shows that this threat has been active and has been in use for several years.
Below is information about domains that were used for second-level URLs.
Unlike one DoD IP address, the other three provided hosting for hundreds of domains. Most of these domains were registered less than a year ago and point to amateur small business websites that use Asian languages.
The domain name nedfortibt.info contains the acronym NED, which stands for National Endowment for Democracy. This organization describes itself on the site:
The foundation openly supports Tibetans in their conflicts with China.
- Our telemetry system shows a very small scale of infection with this threat, and the geography of distribution is limited to such countries as Nepal and China. Previous versions of this malicious code have been fixed by us since 2010.
- The payload is a small fragment of Javascript code that is registered using the Windows WMI subsystem.
- The backdoor uses fake blog websites to obtain information about command C & C servers. These websites are hosted on domains registered in Tibet.
- According to its characteristics, this operation is very similar to previous spy campaigns against Tibetan activists, such as OS X Lamadai and others .
We conducted a detailed study of this backdoor and found out the details of its installation on a compromised computer, the mechanisms it uses to maintain its presence, as well as the details of interaction with the C & C server.
Establish and maintain presence
')
An exploit is used to install the Win32 / Syndicasec malware. Despite the fact that operations of blocking the actions of this exploit by our anti-virus products were recorded, we could not get it all, so we are not sure which particular exploit was used for the attack. Next, the two-step backdoor installation process begins.
At the first stage, the dropper performs some preparatory actions. Checks for the existence of the% SYSTEM32% \ sysprep.exe file. If it is present, the malicious code copies the extracted .cab file to the% TEMP% directory. Further, the contents of this archive will be copied to the% SYSTEM32% \ cryptbase.dll file using the Windows Update Standalone Installer tool (wusa.exe). To do this, use the command shown below.
The .cab file itself is stored in a dropper in open form, with the exception that the archive signature is missing - the first few bytes. These bytes will be added to the memory buffer before it is written to a file on the disk.
To elevate privileges, the dropper attempts to exploit a vulnerability known as COM Elevation (UAC whitelist). A similar method of elevating privileges in the system was used by the Avatar rootkit dropper, which was reviewed by us.
Inside this library, we found a debug line that gives some insight into the project.
The second stage consists in the execution of another dropper, which is stored in% TEMP% \ gupdate.exe. If the sysprep.exe tool is present in the system, the dropper is launched using this tool. When performing the dropper, the privilege elevation technique is also used by exploiting UAC whitelist. If sysprep is not found on the system, the usual command interpreter cmd.exe is used to execute gupdate.exe.
The gupdate.exe executable is responsible for setting the payload to the system. WMI is used for this. It should be noted that in malware this method is quite rare. This tactic was seen in the Stuxnet worm. You can find a detailed description of it in a document from our colleagues at Trend Micro.
The method of installing a payload using WMI has a number of very useful features from the point of view of an attacker, for example, the malicious code is not obliged to be permanently stored as a file on disk. This approach significantly reduces the chances of detecting malicious activity using tools like Process Explorer.
Installing the payload in the system is as follows. At the first stage, the Javascript code fragment is decrypted in the gupdate.exe dropper using normal XOR. An example of this code is presented below in the screenshot.
Then it creates its own WMI classes.
1. Class __TimerInstruction
The malicious code creates a class __TimerInstruction to set an event called “ProbeScriptInit” to the alarm state every 60,000 milliseconds.
2. Class __EventFilter
This class is responsible for the logical combination of a special timer with the malicious code contained in __EventConsumer .
3. __EventConsumer
This class contains malicious code that is executed each time the event is set with the __TimerInstruction code.
The above objects are located in the root \ subscription namespace, which ensures their sufficient secrecy.
Backdoor capabilities and networking
Consider a malicious script that is contained in the __EventConsumer object. The code from this script is quite simple to analyze. It can be seen that it contains URLs that are hard-wired into the code, which are chosen arbitrarily, and are then used to work with the command C & C server through the usual GET HTTP protocol request. We call these addresses: first-level URLs (Stage One URLs). In fact, all of these hard-coded addresses lead to fake blogs on the web pages, where RSS feeds of second-level addresses are used to communicate with C & C servers. The screenshot below shows an example of one of these blogs:
The key element in this RSS feed is a tag that contains an encrypted string between the two delimiters '@'.
The screenshot below shows the script code, in which you can see which procedure is used to decrypt this line.
As a result of the line decryption, another address is obtained, which is called the second level URL (Stage Two URL). This address will be used for actual communication with the command C & C server.
The initial message is sent to the second level URL using the HTTP protocol POST request and contains some basic information about the infected computer. The response to this message is an HTML container div, which contains one or more commands.
Static analysis shows that the received command buffer includes an obfuscated Javascript script that, by means of eval () transformations, extracts another script from itself.
Observed activity
In parallel with the analysis of the code, we tracked the behavior of a special test computer that was infected using Win32 / Syndicasec . After the first few days of monitoring, teams from C & C were recorded. According to the observed interaction of the bot with C & C, it is obvious that this interaction is not automatic, but is controlled by the person behind the bots control console. We came to this conclusion, because every day a different number of commands were sent, sent at irregular intervals.
Below is a screenshot of a fragment of one of the first sessions of bot interaction with a C & C server. If you pay attention to the time stamps, you will find that all commands have been received for more than 30 minutes. It should be noted that each command includes Javascript scripts required for execution. For brevity, we have included the full code for only some functions. Teams with identical time stamps were received in one command buffer.
It can be stated that the operator was viewing the file system on the infected machine, as well as network settings, mapped drives and running programs.
The next day, the operator used another set of commands to collect data about the infected system.
In this session, the operator used similar commands to accomplish similar goals, but they were made somewhat differently. This suggests that in this case we were dealing with a different operator, different from the first one. You can note, for example, the following obvious typo or error in the following line:
ExecuteCommand ('dir c: \\ dir c:');
Second level URL addresses remained unchanged until 2013-04-22. After that a new domain netfortibt.info was added. For information about it, see the next section.
Malicious code history
We found one of the versions of the main malicious script, which dates from July 2010. This script has been uploaded to one of the online Javascript analyzers. The screenshot below shows the differences in the first lines of the script code for the two versions: 0.5.2 and 1.2.0.
By further analyzing the differences between these two versions, we can see the encrypted data in the body of the container title, which refers to the RSS feed and has not been changed in the newer version. On the other hand, it is clear that in the older version, the C & C server did not apply encryption to the commands sent by the bots, but sent them in clear text. The commands were encrypted already in version 1.2.0 of the main script (see the circleDecode () function)
We can see that version 0.5.2 of the script makes calls to the WMI API functions necessary for registering objects in the root \ subscription namespace. This scheme is different from the one used in the newer version 1.2.0, in which this operation depends on the dropper for making WMI calls.
The old version of the script contains only one hard-wired first-level URL, which was still active at the time of writing this analysis. Below is the webpage of this URL.
You can see that only 25 users have visited this page since the date of its publication in September 2010. The decrypted contents of the container title show the inactive second-level URL (hxxp: //.hostaim.com/summer/ieupdate.php).
Another script was found using the same Javascript analyzer. We can see the dialogue between the infected host and the command C & C server starting from 2012. The query line shows that the script version 1.0.1 is running on the infected host.
The above information quite clearly shows that this threat has been active and has been in use for several years.
Below is information about domains that were used for second-level URLs.
Unlike one DoD IP address, the other three provided hosting for hundreds of domains. Most of these domains were registered less than a year ago and point to amateur small business websites that use Asian languages.
The domain name nedfortibt.info contains the acronym NED, which stands for National Endowment for Democracy. This organization describes itself on the site:
The National Foundation for the Support of Democracy (NED) is a private non-profit organization whose activities are aimed at developing and strengthening democratic institutions around the world. Each year, the NED fund pays more than 1,000 grants to support projects of non-governmental organizations abroad, working to achieve democratic goals in more than 90 countries.
The foundation openly supports Tibetans in their conflicts with China.
Source: https://habr.com/ru/post/181217/
All Articles