Many organizations leverage AWS as their cloud computing platform. Allowing access to and from their AWS resources is critical for workloads to operate uninterrupted. This means that an AWS VPC is often seen as a logical extension of the corporate LAN – sometimes connected with a dedicated channel to the datacenter. Conveniently, AWS has service endpoints which provide access to AWS services, even when outbound internet access is explicitly disabled. Network architects enable these service endpoints to leverage cloud services while minimizing the risk of accidental internet-exposure.
The implicit trust of such a network can be abused by attackers to circumvent intrusion detection systems. In this blog post, we’ll show how AWS S3 can be used as platform to host a robust command and control (C2) infrastructure.
Components of our setup include:
1. C2 Server – The host that sends commands to victim systems
2. Victim Payload – The application that gets launched on a victim system to establish reverse connectivity
3. AWS S3 – The communication medium through which commands are sent and responses are received
4. aMALgamous – The program that generates the payload, sets up the C2 and configures S3 to support the communications
During the development phase, I used Boto3 to create all the configurations within S3 and generate custom buckets to house our command and control traffic. However, there were some challenges that needed to be overcome. Initially, my proof-of-concept attempt allowed me to run commands, but the results of those commands were in a world-readable S3 bucket. Uploading the command outputs with hard-coded access keys within the payloads wasn’t an option. The solution was to create pre-signed POST URL requests, which can upload files to the S3 bucket – eliminating the need to embed access keys. Once this issue was solved, configuring the victim payload to monitor for changes in the S3 file was quite simple. The victim periodically polls the S3 file to see if the latest appended command was the same or different from the previously executed command. If it is different, then the command is executed on the victim.
Part of making the victim payload polymorphic and thus more difficult for antiviruses to detect is to randomize all variables, function names and identifiers. Luckily, we’ve already developed this functionality as part of aMALgamous. aMALgamous is a malware and payload generation application that I created early last year. This platform helps us to generate the C2 configuration, S3 buckets and victim payloads.
Having solved all those hurdles, it is now possible to leverage AWS S3 for communicating back-and-forth from our C2 server and the victim host. Our next step will be to expand the functionality to allow our C2 server to manage multiple victim hosts.
Red teamers can use aMALgamous to generate the C2 and payload for the victim. All that’s needed to begin is an AWS account with an IAM user scoped to only have programmatic access to S3.
Blue teamers will only see HTTPS traffic to and from AWS S3 where the TLS encryption certificates used are Amazon certificates. Read and write S3 operations are considered normal network traffic within most organizations.
Clone, star and fork the aMALgamous Github project here: https://github.com/AbrictoSecurity/aMALgamous
