There are many technical whitepapers on the details of this attack that are very interesting to read. Leaving some of the in-depth, technical details out, the process is quite simple. The application synchronizing with the cloud service uses a synchronization token to gain access to the correct account and data. An attacker places malware on the target system (called a Switcher) often via a social engineering attack combined with a malicious e-mail attachment. Once the malware is launched, it moves the victims’ synchronization token to the actual data sync folder. It then replaces that original token for one crafted by the attacker. The new token points to an account the attacker has access to. When the targeted application synchronizes the data sync folder the next time, the target’s original synchronization token is copied to the attackers’ cloud location from where it can be downloaded and subsequently used by the attacker. This gives the attacker access to the targets’ cloud data from any machine. It also provides the attacker the ability to synchronize malicious files (for instance malware infected Word documents) back to the targets’ local data sync folder and even replace commonly used files that the victim trusts. The Switcher malware can copy the original synchronization token back and remove itself at any time, effectively erasing most evidence of the attack. There are many other varieties of this MITC attack method as well, some specifically customized for the targeted cloud platform, some with additional features such as the installation of a backdoor. The principle is the same however and considering the importance of the synchronized data (why else would it be selected to be synchronized in the first place), this is a very dangerous attack method. It is quite difficult to detect a Man in the Cloud attack itself. There is a login process against the cloud service using a different synchronization token (user). Without any further context around this event, the IDS or Proxy logs will at most show that a seemingly legitimate cloud sync occurred. By itself that does not warrant an alarm. A watchful user could analyze the login geolocation history via the cloud different platforms portal, but that is not the most reliable detection method. There is a much better chance of detecting the actual social engineering attack via an e-mail AV gateway, or the subsequent Switcher malware files located on the target host. Traditional or behavioral Antivirus solutions should be able to deal with most of these infections. The benefit of relying on these technologies is that the attack is detected early in the process and at that point, it could still be blocked, either manually or automatically. Once a (partial) MITC attack has been detected, the impact has been assessed, and the evidence has been gathered, it needs to be mitigated. As mentioned earlier, a skilled attacker would have undone all system changes and removed all related malware files already. This is not always the case, however. Some attackers do not worry about leaving evidence. Sometimes either the attack or the subsequent clean-up process fails. In any case, the remaining malware related files will need to be removed. It is also advised to close the cloud account and replace it with a new one. This will guarantee the synchronization token will never be used again, simply because the account has been removed. Different providers might have some methods of forcing a ticket to expire, but a successful outcome would be hard to prove because the attacker does not need to access the target system anymore; the ticket has already been copied. The most successful way to prevent the social engineering attack that is likely to precede the MITC attack is a combination of a comprehensive security awareness training and adequate technical controls. For example, if a staff member has just completed the (yearly) security awareness training, he or she is less likely to open the malicious e-mail attachment which will prevent the attacker gaining a foothold within the organization’s network. If the user does open that attachment, a traditional or next-generation Antivirus product should detect and block the malware, without the need for user interaction. More specifically targeting MITC attack characteristics are technologies such as a Cloud Access Security Broker (CASB). A CASB is either deployed inline where it can function as a proxy or via an API where it can monitor traffic to and from a cloud platform. Both options have their advantages, but the main function of the product is to monitor cloud traffic for account anomalies which are for instance generated by an MITC attack. The MITC attack presents some new and unique challenges for organizations that take security seriously. Having a solid foundation of traditional security controls will certainly assist in detection and prevention of an MITC attempt. It is advised, however, if the security budget allows for it, to invest in some more specific controls such as the mentioned Cloud Access Security Broker. The ever-growing adaptation of cloud technologies by organizations will gain the interest of malicious entities more and more, so it is expected to see new attack vectors like the MITC attack in the future.
