Information Security News
Hackers compromised a download server for a popular media-encoding software named HandBrake and used it to push stealthy malware that stole victims' password keychains, password vaults, and possibly the master credentials that decrypted them, security researchers said Monday.
Over a four-day period ending Saturday, a download mirror located at download.handbrake.fr delivered a version of the DVD ripping and video conversion software that contained a backdoor known as Proton, HandBrake developers warned over the weekend. At the time that the malware was being distributed to unsuspecting Mac users, none of the 55 most widely used antivirus services detected it. That's according to researcher Patrick Wardle, who reported results here and here from the VirusTotal file-scanning service. When the malicious download was opened, it directed users to enter their Mac administrator password, which was then uploaded in plain text to a server controlled by the attackers. Once installed, the malware sent a variety of sensitive user files to the same server.
In a blog post published Monday morning, Thomas Reed, director of Mac offerings at antivirus provider Malwarebytes, wrote:
by Sean Gallagher
Late on May 5 as the two final candidates for the French presidency were about to enter a press blackout in advance of the May 7 election, nine gigabytes of data allegedly from the campaign of Emmanuel Macron were posted on the Internet in torrents and archives. The files, which were initially distributed via links posted on 4Chan and then by WikiLeaks, had forensic metadata suggesting that Russians were behind the breach—and that a Russian government contract employee may have falsified some of the dumped documents.
Even WikiLeaks, which initially publicized the breach and defended its integrity on the organization's Twitter account, has since acknowledged that some of the metadata pointed directly to a Russian company with ties to the government:
— WikiLeaks (@wikileaks) May 6, 2017
Evrika ("Eureka") ZAO is a large information technology company in St. Petersburg that does some work for the Russian government, and the group includes the Federal Security Service of the Russian Federation (FSB) among its acknowledged customers (as noted in this job listing). The company is a systems integrator, and it builds its own computer equipment and provides "integrated information security systems." The metadata in some Microsoft Office files shows the last person to have edited the files to be "Roshka Georgiy Petrovich," a current or former Evrika ZAO employee.
[This is a guest diary by Renato Marinho of Morphus Labs. If you are interested in writing a guest diary: please send suggestions to us via our contact page]
We recently deployed a high interaction honeypotsexpecting it to be compromised by a specific malware. But in the first few days, instead of getting infected by the expected malware, it received a variety of attacks ranging from SSH port forwarding to Viagra and Cialis SPAM to XORDDoS failed deployment attempts. By the third day, it was insistently hit and compromised by Rakos, a Linux/Trojan.
Based on the expected Rakos behavior reported last December by ESET , our honeypot was recruited to a botnet and immediately began attempting connections to other hosts on the Internet, both to call home and to search for new victims. Although it wasnt our initial plan, we noticed that this sample didnt behave like the one ESET described, which got us curious and made us analyze it here at Morphus Labs.
After analyzing and exploiting this botnets communication channel and employing Crawling and Sensor Injection enumeration methods, we did find a network floating around 8,300 compromised devices per day spread over 178 countries worldwide. Considering the recent DDoS attack reported by Incapsula  against a US College, originated from 9,793 bots, which was able to generate 30,000 requests per second during 54 hours, we may infer how potentially threatening is Rakos botnet.
To better understand this P2P Transient botnet behavior and its CC protocol, we listened to its traffic for 24 hours, and after analyzing it, we noticed two kinds of communications: one between bots through HTTP and, the other, between bots and CC servers through TLS/SSL. In this section, we detail the commands we mapped.
Some definitions before start:
A particular node may play both roles.
The connections between Checkers and Skaros are made through SSL/TLS encrypted sessions. It was necessary to intercept the traffic using a classic man-in-the-middle attack to access the messages. See in Table 1 the list of captured commands and its descriptions.
|POST /ping HTTP/1.1||This command is used by Checkers to inform a Skaro its information and stats. It includes: system architecture, operating system, a checker port number (used for bot to bot communication) and machine load (CPU and Memory). In the response, it receives the SSL certificate files (CA, CERT and KEY), a list of up to 30 Skaros addresses and 50 Checkers|
|GET /upgrade/up HTTP/1.1||Command issued by the Checker to get a new list of username/password combinations from a Skaro.|
|GET /upgrade/vars.yaml HTTP/1.1||Issuing this command, a Checker receives a response like the initial parameters. Its a kind of configuration refresh.|
|GET /upgrade/linux-armv5 HTTP/1.1||This command is used to get a new version of the malware binary file.|
The communication between Checkers is essentialto discover their own public IP address. The bots reach each other through HTTP requests using the high random TCP port they bind to.
See in Table 2 the list of commands and its descriptions.
|GET / one bot uses /love to query another for its own IP address and PTR (the reverse name associated with that IP address). There is a zen parameter we didnt realize its function.|
Now that we better understand the CC channel, lets move on to the intelligence gathering phase. The objective here is to enumerate the population of this botnet, classify its nodes into Skaros and Checker groups and get as much information as possible about them. To this end we implemented two standard approaches to size P2P botnets, Crawling and Sensor Injection 
This strategy consists of visiting as many nodes as possible and collecting information about them. The crawler starts by requesting the neighbor list from aseed node and iteratively requests neighbor lists fromevery newly discovered and active node until all bots are discovered .
To maximize our chances of finding an always available and responsive seed node, we investigated the lists of Skaros we collected during the man-in-the-middle process and the /ping commands we collected to discover prevalent IP addresses. Doing this, we found a group of three IPs both present in the section skaro in response to the CC command /upgrade/vars.yaml and in the section proxies in response to the CC command /ping, which could make them good seed node candidates.
To validate this, we queried them manually issuing /ping commands. As a result, two didn width:400px" />
At this moment, we realized that the bots authenticate via theSSL certificate found inthe CC command responses. Using it, we issued another /ping to the same Skaro that, this time, answered with the expected results, including a list of up to 30 Skaros and 50 Checkers. This botnet protection/authentication mechanism indicated to us the importance of this node to the botnet and made us choose it to be our seed node. We decided to call themSuper Skaros.
Finally, we wrote a script to automate the crawling process. The script, written in Python, iteratively requests the seed node for the Skaros it knows. Then is asks these Skaros for the Skaros they know and so on until there is no new Skaro to request. The script also creates a graph of the botnet while discovering it to make it easy to further analyze the nodes and its interconnections.
The second strategy is to inject fake nodes into the botnet as sensor nodes . The objective is to offer the network fake nodes to be contacted by the others while enumerating them.
Given the restricted number of Skaros and Checkers returned by each query, the crawling approach may give us just a limited view of the whole botnet. Even when we tried to repeat the query for the same Skaro, the returned list usually included just a small number of new nodes.
To overcome this problem and to improve que quality of our enumeration process, we decided to apply the Sensor Injection method, which, for this research, consists in inserting fake nodes (Skaros and Checkers) into the botnet and collecting information about the nodes that contact them.
To insert the Checker Sensor, we basically ran the malware binary on a controlled environment preventing it from establishing any SSH outgoing connections and monitored the network traffic to enumerate all bots that contacted it. As the communication between Checkers isnt encrypted, this strategy could give us the possibility to inspect any content posted to or from our sensor.
To insert the Skaro Sensor, we prepared a /ping command with manipulated available, running and addr parameters pointing to the IP address to one of our honeypots and sent it to a valid Skaro. Next, we issued a new /ping width:400px" />
To capture and store the data posted to the Skaro Sensor, we created a simple PHP script to append to a file the received HTTP POST parameters. In Figure 4 there is an example of a Checker posted data using the /ping C width:400px" />
Finally, to maintain our Skaro Sensor alive on the botnet, we could continually send the manipulated /ping command to the Skaros on the network. To implement this, we just configured the /ping request of the Crawling method with the appropriate values. As the Crawling would periodically visit all active Skaros, our Sensor Node would always be propagated.
After defining the methodology and tuning the scripts, it was time to create the environment to execute the experiments, detailed in this section.
As we were dealing with a P2P botnet, distributing the Sensor Nodes in different parts of the world could give us a better view of the botnet, especially if it imposed any kind of communication restriction or load balancing based on geographic regions or IP addresses.
Thus, we distributed 5 Sensor Nodes in the following locations:
Finally, we put our plan into action. The experiments were started simultaneously in all honeypots. Shortly after, the Crawling Process was already querying 30 to 60 Skaros and the Sensor Nodes were receiving connections from the botnet. All as expected.
After 72 hours (or 3 days), we stopped the experiment and started processing all the collected data. The results are shown in the next section.
The experiments generated approximately 5 GB of data amongst PCAP files, HTTP requests, crawled data and graph files that were handled and inserted into an Elastic Stack  and Gephi  platforms for querying and visualization purposes. The results of both enumeration methods are summarized in Table 3.
|NODE TYPE / METHOD||CRAWLING||SENSOR INJECTION||UNIQUE NODES|
As we expected, the crawling strategy gave us just a small view of the whole picture. In fact, it accounted for just 3,15% of the total number of discovered nodes. The other part, 96,84% or 24,839 nodes, was found by the Sensor Nodes.
Each sensor discovered an average of 5,000 unique Checkers and 48 unique Skaros during the whole experiment. Comparing to the Crawling method, its interesting thatalthough Sensor Injection could discover 50 times more Checkers, it discovered 15% less Skaros. It is also worth mentioning that the efficacy of Sensor Nodes depends on the continuous /ping to maintain the Sensor Nodes alive.
To make it easy to represent the botnet and its interconnections, we produced graphs for each crawler. width:400px" />
The other graph shows the real interconnection between nodes, as seen in Figure 6. Here we can see a very thick botnet wherevirtually width:400px" />
Figure 8 represents all the connections received by So Paulo sensor. The big yellow node represents the sensor node. In lilac are the Checkers and width:400px" />
The graph for the other sensor nodes look very much like these differing basically by the geographic position of the sensor node.
The worldwide botnet distribution is shown in Figure 9. It width:400px" />
Another interesting finding of this research is related to the victims width:300px" />
This botnet relies basically on default or easy guessable passwords that devices owners fail to manage. None the less, Open ELEC systems do not even offer an easy way for users to change the default password, as shown in Figure 12 The text was extracted from Open ELEC width:400px" />
In this section are the IoCs (Indicators of Compromise) that could be used to search for this malware in your environment.
$ = upgrade/vars.yaml
$ = upgrade/up
$ = /tmp/init
$ = dalek
$ = skaro
4 of them
This research revealed a network of controlled devices we defined as a Transient Botnet. The term transient refers to the non-persistence aspect of Rakos malware which means that a single bot remains on the network after a reboot only if it gets compromised again, just like Mirai. In other words, we are dealing with a threat that, like many others, counts on the certainty of the abundance of victims and that most them will remain vulnerable even though this vulnerability could be avoided by a password change.
This transient aspect was reflected in the results we found. During the experiments, the number of nodes floated during the period with peaks of 1,700 new IP addresses which could be existing victims we didnt know yet or simply new infected or re-infected nodes. Considering this fluctuation, from the 25084 unique nodes discovered in 72 hours, we may consider an average of 8362 bots per 24 hours which certainly represents risks if they were used together in DDoS attacks, for example.
This individual problem that potentially leads to a global threat reminds us the difficult adoption of BCP 38 (Best Current Practices)  that specifies how Internet Services Provides (ISPs) could individually cooperate by configuring its routers to defeat DDoS amplification attacks over the Internet. The difference is that in password vulnerability problems we don it involves much more devices and, especially, people.
Finally, its worth mentioning that during the 30 days we analyzed this botnet, we didnt notice any malicious actions other them the SSH brute-force scanner itself. It seems that someone is preparing it to be sold or to offer services using it when it gets in the right size. Thinking this way, the innocuous-looking may be a strategy to fly under the radar.
 Rossow, Christian, et al. Sok: P2pwned-modeling and evaluating the resilience of peer-to-peer botnets.Security and Privacy (SP), 2013 IEEE Symposium on. IEEE, 2013.
 J. Kang and J.-Y. Zhang. Application Entropy Theory to Detect New Peer-to-Peer Botnets with Multi-chart CUSUM. In Proceedings of the 2nd International Symposium on Electronic
 Karuppayah, Shankar, et al. On advanced monitoring in resilient and unstructured P2P botnets.Communications (ICC), 2014 IEEE International Conference on. IEEE, 2014.