What is Pitou? A recently spotted spambot malware that shares many similarities from the notorious kernel-mode spambot Srizbi. After further analysis, we confirmed it is a revival of Srizbi. We named this latest malware Pitou. After some in-depth analysis, we found some other interesting technical features and wrote a whitepaper on it.
Why it is called Pitou? The name Pitou came from our colleague's existing detection name for it. We decided to use this family name to avoid confusion. Another reason why we think this spambot deserves a new name (rather than continuing with the Srizbi moniker, that is) is because the malware code has been completely rewritten with more robust features, including now being equipped with a bootkit.
Where was it first discovered? We first encountered the threat on a client machine that reported a suspicious system driver file to our automated analytical systems. After some manual analysis, we found it to be malicious and containing a payload that is highly obfuscated and protected by Virtual Machine (VM) code. This implied that there was something the malware was trying to hide from researchers. So naturally we decided to do an in-depth analysis.
When was it first seen? The threat was first found in April 2014 based on the dates from our sample collection systems, though it may have existed in the wild at an earlier date. The whitepaper includes more timeline information.
Who should be concerned by this threat? This threat could cause havoc or bring inconvenience to both corporate and home users. The spambot will utilize an infected machine to spread spam emails, which can lead to the spamming IP address being blacklisted in Realtime Black List (RBL) by an Internet Service Provider (ISP). A blacklisted IP address is blocked from sending (even legitimate) email via standard Simple Mail Transfer Protocol (SMTP), which is commonly configured in most corporate email servers. A regular home users meanwhile would be concerned if they use a non-Web based email client, for example Microsoft Outlook, that ends up having its IP address blacklisted by an ISP.
What are some of Pitou's indicators of compromise (IOC)? The threat is not particularly stealthy compared to other modern rootkits. We list a couple of IOCs in our document for someone (reasonably technically astute) who is interested in quickly identifying if their machine is Pitou-infected.
We believe you should never pay a ransom to online criminals. The reason is quite simple. File-encrypting ransomware holds the victim's personal files "at ransom" until a payment is made. For the scheme to work, the victim has to believe that paying up will help. However, the only certain outcome from paying criminals is to encourage them to continue their malicious activities: paying the ransom might not actually get you your files back. Case in point, a recent ransomware family commonly known as SynoLocker.
SynoLocker targets network attached storage devices manufactured by Synology. Once a device has been infected with SynoLocker, the malware will proceed to encrypt files stored on the device. It will also present the victim with a ransom message demanding payment in return for decryption of the files. Here, however, the criminals behind SynoLocker make a false promise. In many of the cases we have observed, the decryption process didn't actually work or the decryption key provided by the criminals was incorrect.
Even after being double-crossed by the criminals, all hope is not lost. If a victim is able to obtain the correct decryption key, the files can still be restored. For this purpose, we are today releasing a small tool, a Python script, written by us. This tool can be used to safely decrypt SynoLocker-encrypted files as long as the correct decryption key can be provided. The tool does not in any way break the encryption of files created by SynoLocker and it does not attempt to bruteforce the decryption key. It will only work, if the decryption key is already known.
On the left, the beginning of a file encrypted by SynoLocker and, on the right, the beginning of the same file decrypted.
Another use case for our decryption tool is a situation where a user has paid the ransom but can't use the decryption key as they have removed the SynoLocker malware from the infected device. Instead of reinfecting your device with the malware (which is a bad idea), you can use the key together with our script to decrypt your files.
By releasing this tool to the community at large, we hope that we can contribute to undoing the harm caused by these criminals.
We never recommend anyone to pay a ransom.
Our decryption tool, as well as installation and usage instructions, can be found here.
Google uses HTTPS for all search queries. That's good, because it means that all of the questions you ask (a.k.a. your data) will be encrypted. However… regardless of HTTPS, inferences about your searches can still be made by somebody with access to your network traffic. For example:
In the screenshot above, a popular "packet analyzer" displays DNS queries (a.k.a. metadata). We first connected our test device to google.com and performed a search — and then we clicked on the top search result link — and connected to aa.org.
The deductive reasoning skills of Sherlock Holmes aren't required to figure out "alcoholics anonymous" was searched for. And even if aa.org used HTTPS encryption (it doesn't), using DNS metadata, we can still infer the contents of the search data. The connections made offer all the evidence needed.
Lately, our eyes have been caught by the rise of Ransomware families. It is very evident that the bad guys are constantly developing this type of malware family as seen in our previous posts about CryptoWall and CTB-Locker and Synolocker. In addition to these families, we have also been observing a rather simpler type of Ransomware, yet pretty active and very much alive since it was first encountered in 2013 - Browlock.
Compared to other Ransomware families, Browlock does not encrypt the victim's files, and does not add nor run any files on the victim's machine. It only scares the user by �locking� the browser with an alert that claims to be from the police or authorities, stating that the victim has committed a crime by viewing child pornography website or downloading pirated software. It prevents the user from closing the browser, but terminating the browser process using task manager, for example, resolves the problem.
The following are statistics taken from Browlock hits in our telemetry from June onwards.
According to our statistics, the target victims were users visiting adult sites. More than half of them were redirected to Browlock pages after going to adult-related websites. Others were redirected through the use of ad networks. We didn�t notice any adult website that stood out from our data, however, for the ad networks percentage, almost 60% were from trafficbroker.com alone.
Browlock's landing pages have different IPs and URLs from time to time. You may see more observation of this from malekal�s website . The URLs may look random, however it has noticeable patterns. Below are some examples:
From the month of June, we have observed the following most reported URLs in our upstream, with its corresponding IPs where it is hosted:
The graph below shows the duration of these URL patterns being actively reported in our upstream. It seems that on average, Browlock was able to keep a single URL pattern of its landing pages for about two weeks to a month long.
We have also noticed that United States, United Kingdom, and countries in Europe were the most affected.
We�ve seen this operation going on for quite a while now, wondering if the bad guys are really getting money from this very simple mechanism. We don�t really know for sure how many victims have given in into paying a ransom from its fake alert message. But what we know for sure, is that while we see this ransomware families being active, we will keep our eyes open to keep protecting our customers from this threat.
On August 10 Xiaomi addressed privacy concerns related to the MIUI Cloud Messaging function of its smartphones by releasing an OTA update intended to make this an opt-in feature, rather then a default one.
Since we already had the phone set up, we downloaded and applied the update to the same Redmi 1S phone we used in the previous testing:
Then we factory reset it. Once the phone restarted, we noted that cloud messaging is now by default set to Off under Settings:
We then went through the following steps:
• Add a new contact • Send and receive an SMS message • Make and receive a phone call
During these activities, we did not see any data being sent out from the phone.
Next, we activated the cloud messaging function and logged into the Mi Cloud. At this point, we saw base-64 encoded traffic being sent to https://api.account.xiaomi.com:
Note that this is now over HTTPS rather than HTTP, as seen in our previous testing. We had to use a HTTPS proxy in order to view what was being passed:
This was a quick test to check if the update had addressed points highlighted in various media reports. Xiaomi VP Hugo Barra has also posted more details of the MIUI Cloud Messaging implementation.
Last week we wrote about a new ransomware family called SynoLocker that was targeting network attached storage devices manufactured by Synology. Initial rumours suggested SynoLocker might be related to the infamous CryptoLocker, so we decided to dig deeper.
On the surface, SynoLocker and CryptoLocker share many similarities, not the least of which are a similar name, similar choice of encryption algorithms and the idea of extorting money from victims. Under the surface however, the similarities quickly end. When first infected with SynoLocker, a unique RSA key pair is generated for the victim. The private key never leaves the malware operator(s) but the public key is stored onto the victim device. This public key can be used to encrypt data in such a way that it can only be decrypted with the associated private key. As long as the malware operator(s) are in control of the private key, they can deny the victim access to their encrypted files.
For encrypting the actual contents of the victims files, SynoLocker uses AES. First an initialization vector (IV) is generated from the size and name of the file to be encrypted. This IV is later used by the encryption algorithm, but it is also used, combined with a randomly generated string, to generate the actual encryption key. Next, the contents of the original file are encrypted. Simultaneously, a so-called keyed-hash message authentication code (HMAC), commonly used to verify the integrity of data, is also generated from the unencrypted data. Finally, the random string used to generate the key is encrypted using the RSA public key. This ensures, that the only way to regenerate the key for decrypting the data, is by first decrypting the random string using the RSA private key.
Diagram of the encryption process and resulting file
Once finished with the encryption of a file, SynoLocker will replace to original with a new one. To the new file, SynoLocker first writes the RSA-encrypted random string. Next, it writes a marker string "THE_REAL_PWNED_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX_1337" (for those counting, there are 40 Xs) which it uses to identify files it has encrypted. After the marker, the IV used in the encryption process is written. Next, the encrypted version of the original file contents is written to the new file. Finally, the HMAC generated during the encryption process is written to the end of the new file. All this is done by SynoLocker in such a way, that were anything to fail or go wrong at any point during the process, the original data would not be lost. Only once everything is done, will SynoLocker replace the original file with the new one. Finally, it will also attempt to overwrite the original file with random data to make recovery more difficult.
A file encrypted by SynoLocker, as viewed in a hex editor (Arrows pointing to beginning of marker string)
When attempting to decrypt files, the above described process is essentially reversed. First SynoLocker obtains the random character string by decrypting it with the victims RSA private key. Next, the string is used together with the IV obtained from the encrypted file, to generate the actual AES key. Finally, the file data is decrypted using this key. At the same time, SynoLocker generates a new HMAC from the decrypted data. Finally, the HMAC of the original data is compared with the newly generated HMAC and only if they match, is the decryption process deemed successful. Again, this ensures, that if anything goes wrong during the process, existing data is not lost.
In addition to the encryption methods used by SynoLocker, we were also interested in finding out more about the infection vector(s) used. Despite our best efforts, we have so far been unable to identify the exact infection vector used by SynoLocker. It is however clear, that SynoLocker is more a collection of files uploaded to the device through the infection vector, rather than just a single malicious binary. These files all have specific purposes and are often dependent on each other to fully function. A list of SynoLocker related files is available at the end of this post.
While analysing the SynoLocker binaries, we have also continued monitoring other aspects of the operation, and it seems the operator(s) are on the move. Recently, the website where victims are instructed to go to for payment instructions, has been updated. The page now includes the notice "This website is closing soon...". The operator(s) also claim that they are still in possession of over 5500 private keys but that they are willing to sell the entire collection for 200 bitcoins.
Recent screenshot of SynoLocker website
Whether the operator(s) follow through with their plans and what that might entail for victims will remain to be seen.
List of SynoLocker related files: /etc/synolock/server /etc/synolock/synosync /etc/synolock/synolock /etc/synolock/crypted.log /etc/synolock/decrytped.log (spelling mistake in SynoLocker) /etc/synolock/RSA_PUBLIC_KEY /etc/synolock/RSA_PRIVATE_KEY /etc/synolock/.restore /etc/synolock/.decrypt /etc/synolock/watch.sh /etc/synolock/uninstall.sh /etc/synolock/watchdogtest.sh /usr/syno/synoman/crypted.log /usr/syno/synoman/decrypted.log /usr/syno/synoman/index.html /usr/syno/synoman/redirect.html /usr/syno/synoman/lock.png /usr/syno/synoman/style.css /usr/syno/synoman/synolockcode.txt /tmp/.SYNO_ENCRYPT_LOCK /tmp/.SYNO_DECRYPT_LOCK /tmp/.SYNO_SERVER_LOCK /tmp/.server /usr/syno/etc.defaults/rc.d/S99boot.sh /usr/syno/etc.defaults/rc.d/S99check.sh
Senior Researcher Timo Hirvonen presented at Black Hat USA 2014, and publicly released a tool which enables dynamic analysis of malicious Flash files. He spoke about it with SC Magazine's Adam Greenberg last week:
Xiaomi phones have made the news off and on in the last few months for their cheap, value for money phones and corporate moves. More recently, there were also reports that these popular devices also silently sent out user details to a remote server. That news came on the heels of other reports of smartphones being pre-installed with suspect apps.
We thought we'd take a quick look into this, so we got our hands on a brand new RedMi 1S:
We started with a "fresh out of the box" test, so no account setup was done or cloud service connection was allowed. Then we went through the following steps:
• Inserted SIM card • Connected to WiFi • Allowed the GPS location service • Added a new contact into the phonebook • Send and received an SMS and MMS message • Made and received a phone call
We saw that on startup, the phone sent the telco name to the server api.account.xiaomi.com. It also sent IMEI and phone number to the same server:
The phone number of the contacts added to the phone book and also from SMS messages received was also forwarded.
Next we connected to and logged into Mi Cloud, the iCloud-like service from Xiaomi. Then we repeated the same test steps as before. This time, the IMSI details were sent to api.account.xiaomi.com, as well as the IMEI and phone number.
At this point, this was just a quick test to see if the behavior being reported can be confirmed. In response to the reports, Xiaomi itself has released a statement addressing potential privacy concerns (In Chinese on the company's Hong Kong Facebook page, with an English translation linked).
It seems malware authors have recently taken a liking to the network-attached storage (NAS) devices manufactured by Synology Inc. First they were hit by Bitcoin mining malware in the beginning of this year and now by file encrypting ransomware similar to CryptoLocker. NAS devices are used by home and business users alike to easily store and share files over a network. Many, like ones manufactured by Synology, also feature remote access. In this case, it would seem hackers were able to abuse the remote access feature, possibly by exploiting a vulnerability in older versions of the Synology DSM -operating system, to gain access to the devices. Once they had access, they proceeded to install a ransomware they have dubbed "SynoLocker".
Once the device has been infected with SynoLocker, the malware will proceed to encrypt files stored on the device. It will search the device for files with extensions matching a hardcoded list (shown below). Extensions are matched such, that only the beginning of the extension needs to match the hardcoded list. This means, for instance, that both .doc and .docx files will be encrypted, since the list contains ".do".
Extension list hardcoded inside SynoLocker
Once all files have been encrypted, SynoLocker will present the user with a ransom message. The ransom message instructs the user to first download and install the Tor Browser Bundle. Next, users are to browse to a specific website on the Tor network. On that website, users will be further instructed to make a payment of 0.6 BTC (approximately 260� or 350USD) to a specific Bitcoin wallet. Once payment has been received, the malware author(s) promise to supply the user with a decryption key for recovering their files.
Screenshot of the SynoLocker page on the Tor network as presented to victims
The ransom message presented by the malware also purports to describe the technical details of the encryption process. The process described is very similar to the process used by the infamous CryptoLocker ransomware family. The process begins with the generation of a unique RSA-2048 keypair on a remote server. Next, the generated public key is passed to the malware. When encrypting files, the malware will generate a separate, random 256-bit key that is used to encrypt the files with the AES-256 CBC symmetric cypher. The key used for this encryption process is next encrypted with the RSA-2048 public key and stored on the device before being removed from the device memory. If implemented correctly, this process ensures, that the only way to restore the encrypted files is by obtaining the RSA-2048 private key and first decrypting the file containing the 256-bit encryption key used.
Based on our analysis of SynoLocker, the malware author(s) have followed through with their threats and have properly implemented the process described. Sadly this means any files stored on the NAS device will have been lost unless the user has kept a separate backup. There have also been reports of users paying the malware author(s) and successfully receiving the RSA-2048 private key and decrypting their files, but we strongly discourage ever paying malware authors. It only encourages them to continue their malicious work.
This summer has included the appearance of two strong new malware families onto the file encrypting Windows ransomware market: CryptoWall and CTB-Locker. Of these, CTB-Locker has been the more advanced family, with its use of elliptic curve cryptography for file encryption and Tor for communication with the command & control server. CryptoWall, meanwhile, has used the more traditional combination of RSA and AES for file encryption and HTTP for C&C communication.
At the end of last month, however, a new version of CryptoWall emerged into the wild. This latest version is mostly identical to earlier versions in functionality but with one important difference. CryptoWall now also uses Tor for communicating with its command & control servers. Like CTB-Locker, CryptoWall doesn't take the traditional easy approach of using the legitimate Tor-executable obtained from the project's official website, but instead uses it's own obfuscated version of Tor.
On the left, CryptoWall with Tor functionality, and on the right, CryptoWall without Tor functionality. Note that except for the call to f_setupTorCommunication(), the code is identical.
The approach used by CryptoWall is interesting. First, it attempts to connect over HTTP to a number of hardcoded URLs. From these URLs it attempts to download an RC4 encrypted file. The file is structured to first contain the length of the encryption key used, followed by the key itself. Next it contains the length of the actual payload and finally the payload itself. Once the malware has successfully downloaded the payload and decrypted it, it is copied to a newly allocated memory segment and a new thread is created to execute the payload.
Beginning of the downloaded payload as viewed in a hexeditor
The payload itself is a custom version of Tor wrapped inside two layers of obfuscation. Once both layers have finished execution and unpacked the final code into memory, the payload will attempt to establish a connection to the Tor network. Once the connection has been established, a flag value will be set by the payload in a global memory buffer shared by both the payload thread and the original CryptoWall thread. The payload will also set a pointer in the same buffer to point to one of the payload's functions. This is the function that is actually responsible for sending and receiving data.
Once the original CryptoWall thread sees that the global flag has been set, it will then continue with its own execution. The addresses of three command & control servers on the Tor -network are hardcoded in the original CryptoWall binary, not in the payload. The actual message contents of the C&C communication are also handled by code from the original binary. The payload is only responsible for handling the Tor-connection and sending and receiving the data.
Perhaps ransomware operators were switching from CryptoWall to CTB-Locker. Or perhaps the author(s) of CryptoWall just don't like being second best. In any case, the competition for nastiest piece of ransomware is still on!
We have received reports about a Linux malware known as Backdoor.Gates.
Analysis showed that this malware has the following features:
• Collects information on the compromised system, such as OS version, hard disk size etc. • Connects to a C&C server for further information. The server address and port are RSA-encrypted. • Can perform a host of different DDoS attacks: • TCP-SYN flood • UDP flood • DNS flood • ICMP flood • HTTP flood • DNS Amplification
So far we have seen the following C&C server addresses and TCP ports:
It's notable that this backdoor makes use of this file for its installation:
/etc/init.d/DbSecuritySpt
Interestingly, the string "DbSecuritySpt" is a service name also used by another, a Windows malware. After a closer look, we found out that they are more alike than we initially thought.
Both of them use the same names for the main file and the dropped components. For example, the main component is named as "gates" in the Linux version, and "Gates.exe" in the Windows version. The attack tool is called "bill" in the Linux version and "Bill.exe" in the Windows version. The DNS amplification library is "libamplify.so" or "libamplify.dll", and so on. This was too much of a coincidence, so it turned out pretty quickly that they are actually recompiled ports of the same malware.
The malware is written in C++ and the compiled code, by a quick glance, looks quite different, but closer investigation reveals that they must share the some code base. There are some OS-centric portions of the code, such as thread handling, service installation (on Windows, it is installed as a service "DbSecuritySpt", while on Linux it is a startup script in /etc/init.d/DbSecuritySpt). However, there are other similar parts, such as a simple file handling which uses fopen() and fread() among others. Using those standard C-functions is quite uncommon for a Windows programmer. It is then most likely that both variants are compiled from the same code base, with some heavy platform-specific #ifdef's.
Screenshot of Windows code:
Screenshot of Linux code:
With a multi-platform malware like Backdoor.Gates, it is always interesting to find out how it is installed. We don't fully understand this yet. Based on initial analysis, there seems to be no automatic propagation or exploit functionality in the malware. The reports that we have received indicate that the malware was installed using weak SSH-server passwords, at least on Linux boxes.
More analysis on the Linux part of Backdoor.Gates have also been published by Kaspersky and DrWeb.
