Attackers are using cloud services to mask attack origin and build false trust

Source- techrepublic.com

Security experts love talking up the importance of trusted websites. Google’s dominant Chrome browser—which has held about two-thirds of the browser market share all year—emphasized the importance of this with its lock icon, indicating that traffic was encrypted. It’s a useful heuristic, easy for end users to understand. Lock equals security. It’s skeuomorphism at its best, but it lulls users into a false sense of security.

A Wednesday report from Menlo Security finds that attackers are using cloud hosting services to avoid detection, opting to host trojans from websites like storage.googleapis.com, rather than on their own infrastructure. It is difficult to understate the convenience of this—think of all the benefits cloud computing offers the enterprise, the cost savings of building out your own servers, etc., and apply those benefits to cybercriminals. The minimized initial cost makes cloud services undeniably attractive for malicious uses.

So, imagine a user follows a link in a phishing email to download a trojan from storage.googleapis.com. As far as the user knows, the origin is Google, or someone using Google to store data. It’s got the lock icon, and it has Google in the URL, so it should be trustworthy. For IT professionals, if you have a blacklist or whitelist of acceptable domains, this inevitably must be allowed—use of Google is so entrenched that even if your organization uses another platform, enough of your vendors or clients probably use Google’s ecosystem that attempting to block this would bring business to a standstill.

This is an unavoidable problem that cannot be solved programmatically. The only workable solution is educating users that the “it’s from Google, so it must be secure” train of thought is not as ironclad as they expect it to be.

Oddly, it is at this junction that the Menlo Security report derails, violently, in a high-speed accident, as if a maglev train suddenly tried to merge onto rails designed for a steam train. Vinay Pidathala, director of security research at Menlo Security, makes the colourful claim in the accompanying press release that the origin-masking properties of this attack mean “Botnets will decrease, and RAT malware will increase due to the ability RATs give attackers to customize and control every step of the attack. Once they get in, they can live off the fat of the land in the enterprise.” He adds, “We will continue to see an increase in cross-platform malware, similar to the malware we’ve seen in this specific campaign… [as] attackers only need to write one file to attack both platforms.”

In reality, the rise of the hastily designed and minimally secured Internet of Things (IoT) devices will provide malicious actors countless targets to build botnets out of, to say nothing of traditional botnets of compromised servers and workstations. Routers are also increasingly attractive targets for malicious actors, as upward of 500,000 routers were infected earlier this year as part of the VPN filter attack.

Additionally, the “cross-platform malware” Pidathala describes cannot even be described as low-hanging fruit. It’s fallen to the ground, decomposing. The campaign analyzed in the Menlo Security report relies on VBScript and JAR files (optionally zipped) to download and execute the malicious payload, which is theorized to be related to the Houdini malware family, from 2013. How, precisely, VBScript is intended to be cross-platform is unclear.

Looking at the calendar, 2019 is just weeks away. If workstations in your organization are currently deployed with Java SE installed, strongly consider re-imaging them—assume they are already compromised, so there is no point to just uninstalling Java—with an OS image which does not have Java preinstalled. Likewise, Trend Micro offers a quick guide to disabling execution of VBScript by disabling Windows Script Host.