Last week a friend stopped by my desk with a worried look on his face. He knelt down and showed me the screen of his laptop where there was a virtual terminal open:
After looking I asked what the system did, he said it was just a GitLab server for a personal project. I went ahead and killed the process that was still running, then switched the executable bit off on the binaries under the directory referenced above. Thinking it might be something interesting I showed Derek, who was visiting at the office. We helped our friend back up his data from the server and asked if we could have a copy of the software that was dropped on the there, you know, for science. Happy to have had a hand with getting his data off the server our nameless friend agreed to let us have a look, and write about what we’d found.
We could see where the attackers had pulled their toolkit from, and wanting an original copy of the binaries we went ahead and pulled them down through an anonymizing proxy to a clean Kali instance.
As a programmer I was interested in the tools. From the above I could see an order of behaviors so I started with the contents of x.tgz. The first thing I wanted to look at was that start script in x.tgz. It turned out to be a bash shell script:
Walking through the script step by step we see that it starts with an error check to see if it was invoked with the correct number of arguments. If not it prints a help message in Romanian “Tasteaza: ./start canal” or “Type: ./start channel”. Moving on we get a call to ifconfig which parses out the local link addresses and sets a variable to count them. A banner is printed, a quick Google search on the banner brings up an interesting blog post about how nothing has changed in ten years, written in 2013. So, I guess nothing has changed still.
Back to the file: We launch something for each of the link addresses we found. That’s the ./inst file. Let’s have a look.
As we had expected this file is setting up bots. The top of the file is full of “denominations” the last 52 lines contain the logic that pulls the arguments and denominations to configure the bots. We can see what the argument ronnie was for – it sets up “Ronnie” as the channel name. Back in start we get a final few calls. One of them completes the install, the next is to set up the autorun for updates and finally, run the malware. These were pretty basic. The attacker added some iptables rules, created a user named bin, and gave the user root privileges. Finally an email is sent to a Gmail address hardcoded into the rinst.e file, it seems to be mailing out a count of interfaces and a hostname.
The next step our attacker took was to download and run some scripts from a file called “ryo”. We had also obtained that file. Again it’s a series of scripts these simply set up psyBNC, which is along the lines of cloaking an IRC connection. The documentation for the project is from 2003 and development was stopped in 2009. Looking through the rest of the launch we see the run file launching an executable called proc, the GCC version is 2.9 and the OS is RedHat 7.1. So, very old.
The attack was rounded out with something called Pydrona. These executables appear to be the most recently compiled (gcc 4.3.4). One is related to another executable which our attacker had previously deleted: Xhide. The software is meant to hide a process. The other claims to be Drona Turbata 3.0 (Python version). Which translates to … “angry drone” from a mix of Italian and Romanian. I’ve not had time to further play with these.
Conclusions: Some things never seem to change. The attack that got my friends’ Git server is described in a blog from 2013, where the author is arguing that things haven’t changed since the early 2000s. Here we are in 2016, and I’m looking at very nearly the same binaries. This attack is a recipe, it works in stages, and is almost entirely scripted, and it will continue being used until it stops working, which it clearly hasn’t yet.