An AWS development company that provides full-scale cloud consulting and AWS application development services has recently been compromised. They try to maintain cyber hygiene by applying numerous procedures and safe development practices. To this day, they are unaware of how malware could penetrate their defences. We have managed to obtain a memory dump and isolate the compromised server. Can you analyze the dump and examine the malware's behavior?
The downloadable files for this challenge are a Linux memory dump and its corresponding volatility profile.
For this challenge, I wanted to demonstrate that no one is impenetrable. Even if you work in a hardened environment and apply lots of safe development practices, there is always room for human error. So instead of using the most common attack that relies heavily on human error, phishing, I started searching for other alternatives.
I stumbled upon this incident where malicious actors crafted a backdoored python package based on a famous Amazon Web Services Software Development Kit for Python and published it on PyPI. The package was named botaa3 instead of the original name boto3. This attack targets people that tend to write URLs manually instead of copy-pasting them. For this reason, while recreating the incident, we tried to make our malicious repository’s name as evident as possible so none could mistakenly install our backdoored package instead of the original one.
For the malware itself, I wanted to use a fileless technique where it would require players to get more familiar with volshell and manually inspect the memory dump. I first found this tweet by inversecos where she demonstrated how somebody can detect two types of Linux fileless attacks in live systems. This tweet referred to this research presented in Zeronights 2018. This research showcased how it is possible to use the memfd_create syscall in multiple programming languages to execute an ELF file directly in memory. All the pieces came together at this point, as I decided to combine those two techniques in one challenge.
Now let’s proceed to the challenge’s solution.
Volatility does not provide Linux profiles by default. Thus, we need to create one and then configure volatility to use it. Since the profile file is provided as a downloadable, we only need to configure it.
After downloading volatility from GitHub, we need to copy the profile file into the path volatility/plugins/overlays/Linux.
Firstly, when investigating a memory dump, a healthy habit is to enumerate the running processes.
We notice that the user developer is currently logged in to the server via ssh. The user's id is 1000, and as a result, we can see that the user is also the owner of the process 1451 and 1420,1295, which are bash processes.
Our next step would be to enumerate the bash history.