MilkyDoor, a recent malware discovery by Trend Micro, is an example of how attackers can use heavier hitting methods for simpler ends. Named after one of its command and control (C2) domains, MilkyDoor uses a combination of application repackaging and proxying to establish a botnet of infected devices for defrauding advertising networks. It is a variation on previous malware such as DressCode and NotCompatible seen in 2016 and 2012, respectively.
SOCKS and SSH Tunneling
SOCKS, or Socket Secure, is a proxying protocol that can be used to relay traffic. This makes it a good choice for advertising fraud or denial of service attacks: by creating a network of devices to relay requests through, an attacker can generate a significant amount of traffic to a site of their choosing from a wide range of sources.
One issue with this is that if the device is behind a firewall, or is using network address translation (NAT) to share IPs, the SOCKS proxy will not be accessible to the attacker. This, however, is a problem with known workarounds – people have been using common network tools to get around firewalls for a long time, whether for bypassing smaller content filters such as those found in the workplace, or larger ones such as the Great Firewall of China.
One tool for doing this is the ubiquitous Secure Shell (SSH) tool, normally used for securely logging in to a remote server. SSH can be used to tunnel other traffic to a remote server, and is often allowed through firewalls due to its necessity in systems administration. One extra feature of SSH is port forwarding, sending data received on one port to another. If a device behind a firewall can SSH out to a publicly accessible server, it can create a reverse tunnel by forwarding a port on the internal device to one on the outside server. Combined, SOCKS and SSH reverse tunnels allow an attacker to send traffic from devices on internal networks.
It’s worth noting that reverse tunneling through SSH connections enables attacks behind an enterprise firewall. Thus we consider MilkyDoor an enterprise threat.
Mobile Botnets: Dangerous, But Not New
MilkyDoor is being compared to DressCode, another Trend Micro finding from August 2016. DressCode, like MilkyDoor, used a SOCKS proxy to issue commands to infected devices and allow for an attacker to see into internal networks.
Going back another two years to November 2014, we can look at NotCompatible, a mobile botnet that had all the features of MilkyDoor and more, including encrypted end-to-end C2 communications, peer-to-peer communication, and a multi-tiered C2 network architecture used to hide researcher analysis. NotCompatible was observed in use for more than just advertising fraud, including scalping tickets, sending spam, and brute forcing WordPress logins. It was a much more featured botnet, likely for hire, that was observed in development as early as 2012.
Going back even further, the first mobile botnets were observed as far back as 2010, with advertising and install fraud first observed in 2011.
Mobile botnets are a problem, but not a new problem. So, why is this an issue now?
While the modus operandi of proxying is not new for advertising fraud, adding tunneling to the technique is cause for additional concern–because it enables attacks behind the firewall and therefore puts enterprise infrastructure at risk. The ability to send commands directly to devices on internal corporate networks is useful for an attacker, not just for proxying, but for anything else that may require visibility into an internal network. The same techniques are used in targeted attacks to compromise additional systems, perform reconnaissance, and exfiltrate data.
We therefore are seeing the emergence of mobile attacks that create a platform for instigating enterprise attacks. As we saw with Switcher, a malicious mobile app can get access within a trusted zone in an enterprise and launch its attack against the internal network. While neither MilkyDoor nor Switcher are terribly sophisticated in perpetrating such attacks, it’s probably a matter of time before apps such as those will be serving up malicious payloads not unlike those used by APT attacks.
Following mobile security best practices will help prevent device compromise by MilkyDoor or any other mobile botnet agent. We recommend the following:
- Users should only install apps from trusted sources
- Users should read the app details and reviews to look for warnings before installing
- Enterprises should use a security product to evaluate device risks and application behaviors before being allowed access to enterprise resources.
Additionally, enterprises can use their firewalls or IDS to block or monitor suspicious activity, such as SSH or proxy connections from a mobile device.
For Appthority customers:
Appthority customers are automatically protected from MilkyDoor. Appthority’s Mobile Threat Team (MTT) security experts actively manage a set of threat compliance policies and dynamic threat risk indicators to protect your enterprise from malicious mobile threats, including this one. These policies are constantly updated as new threats appear and are included in your Appthority subscription.
Appthority users can also identify risky application behaviors, including “Uses Java Secure Channel” for identifying the use of a SSH library, “Uses Remote Website IP Check” to identify the use of external resources to determine a device’s public IP, and “Infected by MilkyDoor” for presence of the malicious app. These behaviors can be used for identification and remediation of risky apps.