Cloud platform comparison for malware development

Abstract

The cloud platforms such as AWS, Google Cloud or Azure are designed to cover most popular cases in terms of web development. They provide services that make it easy to create a new user based on his email address, provide tools for inter-service communication, tools to manage the access rights of different users. Malware and botnet development however is more of a corner case, where the client application running on the victim’s machine does not have an email address or a google account to authenticate itself and it does not run directly in the cloud, what can make it more difficult to manage the appropriate access rights. Also, the potential attacker may not want to write his own selfcontained service, since, especially when managing a large number of clients, it might be much cheaper to run the backend serverlessly. The big security companies always aim to lower the cost of development and maintenance of bots in order to provide their customers with their penetration expertise faster and cheaper. The paper collects he data through the compilation of scientific publications regarding the botnet architecture and communication, as well as technical documentations regarding each of the cloud platforms discussed in the paper. Additionally proofs of concept are implemented for each of the proposed architecture in order to verify the validity of the approach, as well as measure the performance of the proposed solution and uncover hidden costs related to running the application in the cloud.

The following paper explores possible malware backend architectures for different cloud platforms, aiming to optimise the performance, minimize the development time while keeping the code easy to maintain and to minimize the execution cost. After implementing proofs of concept for the standalone server-based CnC application as well as serverless running on GCP, AWS and Azure, it has been concluded that Azure is in fact the best platform for this sort of implementation due to simplicity of the architecture as well as ease of the implementation, while halving the execution costs compared to the standalone approach.