The Anti-virus Times

Thursday, November 2, 2017

It was on Wednesday, October 25, 2017, that media outlets trumpeted another encryption ransomware outbreak; speculated who was behind the attack on Russia, Ukraine, and Germany; and assessed how the anti-virus market would be affected by it. For starters, let's see what DPH:Trojan.Encoder.32, a.k.a. Bad Rabbit, really is.

First, we need to determine its distribution method. Attackers hijacked several news portals (according to media reports, Fontanka and Novaya Gazeta were affected) and deployed JavaScript code. All in all, this is hardly unusual—as we’ve mentioned many times before, over 80% of sites are vulnerable. Malicious code can be embedded in a web page or scripts, or it can be downloaded from another site while a compromised page is being loaded by a browser. The options are many.

We have also often mentioned that compromising a site known to be frequented by a certain target group may allow for a very successful attack especially if malicious code is deployed before the number of visitors reaches its peak—e.g., at the end of a business day.

http://blog.ptsecurity.ru/2017/09/web-apps-attacks-2017.html

In the case of this attack, site visitors were prompted to install a Flash Player update. This means that users had to click on the Install button with their own hands in order to launch the dropper Trojan.

This raises several questions.

• Question: #1. What are the affected companies' employees doing on news portals during work hours? Clearly some staff need to read the latest news to do their jobs, but why then are their computers connected to a corporate network that facilitates access to the most important corporate assets?
• Question: #2. Why are users allowed to install new applications?
• Question: #3. Why was JavaScript enabled in their browsers?

Three questions. If these security issues had been addressed, no rabbit outbreak would have happened. DPH:Trojan.Encoder.32 exploited no vulnerabilities—all the work was done by users.

Please note once again that Trojans (and DPH:Trojan.Encoder.32 is a Trojan) can't spread on their own—users do that for them.

As far as we know, DPH:Trojan.Encoder.32 doesn't use any techniques to bypass the UAC. Users themselves are agreeing to launch the new application.

• Question: #4. Was UAC enabled on the compromised computers, or did someone toggle it off because it annoyed them?

Once launched, DPH:Trojan.Encoder.32 looks for the processes dwengine.exe, dwwatcher.exe, dwarkdaemon.exe, and dwservice.exe—if Dr.Web is present in the system, the first encryption routine is not executed. Apparently this is done to avoid early detection. DPH:Trojan.Encoder.32 also attempts to modify the MBR. Dr.Web blocks this operation.

• Question: #5. Why weren’t the computers running a modern-day anti-virus possessing proactive protection features? The anti-virus would have been monitoring all running processes and would have detected any malicious programs that hadn't been analysed by an anti-virus laboratory. How many times do we need to emphasize the fact that simple anti-viruses, which rely solely on their anti-virus engines, pave the way for infection?

After that DPH:Trojan.Encoder.32 attempts to scan the network for shared directories. Again, no vulnerabilities are leveraged. The ransomware uses a hardcoded list of standard logins and passwords.

• Question: #6. How many times do we have to say that passwords like 12345678 protect nothing?

In this issue we didn't try to focus on providing a description of this new encryption ransomware program. The description is available here. We're just trying to point out that if basic security measures had been implemented, the outbreak never would have happened. But it did occur (not on computers protected by Dr.Web, however).