Attacking the development team using multicloud storage services.

Generally, in development areas, there is a habit of generating scripts to automate repetitive processes such as updating the repositories and packages of the system or of applications that may well still be in the development phase, later going through tests and end up in production.

That repository could well be hosted on #GitHub or on any storage service from the various cloud service providers #Azure, #AWS, #GCP or #Oracle that allows you to store any file, such as buckets or storage accounts.

And the script (update_repo.sh) that performs this process may well perform these 4 actions:

#!/bin/bash

# Download repository
aws s3 cp s3://labs3-00/dev.tar.gz dev.tar.gz --no-sign-request --region us->

# Unzip package
tar -xzf dev.tar.gz

# Execute application
python app.py

# Clean temporal files
rm -rf dev.tar.gz dev        

But what happens if in the first download action an error appears telling us that this resource does not exist.

Thinking like an attacker, this is an opportunity to create the storage resource and all files with the same name and format with malware capable of evading EDR or XDR solutions.

It may be the case that this development team has been notified that the repository is not yet public at that time, so they are invited to continue validating over a period of time.

And just at that moment one of the members of the development team with malicious intent occurs to create this bucket with the same name that is in the script as well as the compressed file and the application.

With a small detail, this app.py file, has hidden malicious code that allows a remote shell to a command and control (C2) server that this malicious developer controls by some common port, for example 80, 8080, 443, etc.

This malicious application may contain some examples of a reverse shell such as those found in the swissky repo's Payloads All The Things.

And the C2 server where the connection will be received by the victim can be any of those shared by the community and can be consulted here.

Then, the next time the other members of the development team run your script again, they will inadvertently send a privileged remote shell connection to this other team member with malicious intent.

And at this point this attacking developer has remote control over his partner's machine and what he can do afterwards will only be limited to his intentions, his creativity and his technical skills.

This can be replicated in the other cloud storage services and the only thing that changes is the command to connect to the command terminal corresponding to each cloud or download it using wget.

Here are some examples.

Azure

az storage blob download --account-name <STORAGEACCOUNT NAME> --account-key <ACCOUNT KEY> --container-name <CONTAINER NAME> --name dev.tar.gz --file /ruta/local/dev.tar.gz        

GCP

gsutil cp gs://<BUCKET NAME>/dev.tar.gz ruta/local/dev.tar.gz        

ORACLE

oci os object get --bucket-name <OBJECT STORAGE> --namespace <NAMESPACE> --name dev.tar.gz --file ruta/local/dev.tar.gz        

With motivation, skills, and opportunity, an insider can turn attacker and trigger a security crisis.