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.
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