It’s usually all quiet for my little honeypot in Internetland. But every now and again
something interesting will come through. This would definitely be one of those times.
I started writing this post at 30C3 simply because someone was gracious enough to sit with
me and actually reverse the files I pulled from this attack. He gave me a couple of ideas
for what the sample could be, but until we can actually pull out the C&C communications or
the second stage payload, this will all be speculation. As you will see when you read this
post there is a lot of speculation on what’s happening. I’m hoping this will be the first
part in a series as I dig into this malware sample.
The Attack
A user from 186.47.114.23 logged into my pot in the middle of December with the username
and password combination “root / admin”. Here’s the session recording:
IP / Domain analysis
Using the Virustotal API I was able to glean this information for the domain
Looking at the dates of the evilness, we can see that it’s been around for a while.
The IP address is different, but that’s no real surprise.
The two IP addresses (218.154.164.110 & 176.9.51.229) found in the VT dataset didn’t
reveal anything interesting. I should really get my IPInfo.py script up and running again…
Analysis of the initial payload
So they’re going to wget a file, but the strange thing for me was the “busybox wget…” part.
I’ve not seen this before. After chatting with some folks who are a lot more intelligent
than me as well as reviewing the file types that were downloaded, it seems that this
malware was perhaps intended for a router or switch or some such embedded device. That may or may
not explain the “busybox wget” shenanigans…
Here’s the contents of “wgsh” which is a simple shell script file.
So the script attempts a bunch of downloads and then some fun stuff with those
downloaded files.
Here’s the “file” output for the files that were downloaded
Strangeness
Before we did into this, what was more interesting was that a couple of days after this initial
attack, I had a repeat visit. The attack was the same only the downloaded file was slightly
different. Here’s the diff…
Seems someone made a quick fix to the script file as it may have failed. Either that or they didn’t
notice that the “cd /var/run” command failed in their first stage script.
I wonder if this was just a generic fix or if someone actually checked the output from their
initial attack and made adjustments accordingly.
Onward to scripting shenanigans
Looking at the script file “nvr”, we have a couple of commands I’m not too familiar with.
One of the commands also highlights why this script probably failed…IF it errors out
like I think it would…
Would this script work ? Looking at it, I’d say no because of the broken inverted comma
thing. But having never seen this command before, I could be wrong. It’s at this point
of writing this blog post that I reach for a Flora Mate and do a little digging on the
nvram command…
A quick Google search for “nvram set rc_firewall” brings up the DD-WRT wiki page which
could give an indication as to what the Malware sample was looking for…
I’d say that this little piece of awesomeness is an attempt at persistence on the affected
device. It’s going to add a little bit of scripting to the rc_firewall. The script will
download and run the three files mentioned previously, sleep for a while and then reboot,
every time the box/server/device boots. It’s also a little sneakier than saving to
rc_startup (if I understand this correctly), which is probably what a savvy tech would
look at first when troubleshooting / performing incident response.
Looking at the next couple of lines in our script we get
This is plainly an attempt at persistence on the device. Unfortunately the “cron” file is
stripped and encoded (more on this later) so getting the actual payload for the
file is going to be tough.
The last couple of lines
are finishing things up. The cfgmtd command will write the changes to /etc to flash and
allow the device to be rebooting without things going too horribly wrong. I’m not entirely
sure why they did this after the first “nvram commit”. Perhaps to separate the two attempts
at persistence. Finally the attackers remove any trace of their initial infection.
The downloaded files
Unfortunately I can’t really give too much information on the downloaded files as the
reversing done on them was definitely above my pay grade. I’ll see if the guy who
did the grunt work is keen to give a little more information…
Again…
And file sizes…
Looking at the file sizes I’d say that this is the relationship….
And of course hashes…
I should probably run these files through ssdeep…
Pushing the files through strings doesn’t yield anything interesting. The fact that they’re
stripped doesn’t help at all either. The guy who helped with the reversing mentioned a
couple of things (I’m paraphrasing here):
This was the interesting part for me. It looks to me like the authors are hiding the good
stuff inside the existing ELF binary much as you would do with a secondary infector/payload
in the resources section of a PE file. Why they didn’t just pack it is beyond me currently.
The reversing done on these files was quick and dirty between dinner and talks at 30C3 so
it’s definitely not a complete pass. The reverser mentioned that with a couple of well
placed breakpoints and a debugger, you could get to the payload of the files.
Unfortunately neither of us had an ARM or MIPS based system with a debugger setup and
ready to go. I may see if I can do something with my Raspberry Pi tomorrow…
In summary (sort of)
I’d say the malware here is possibly something looking to infect and stay on a router or
switch out there on the Internet. With all the files that were involved it’s likely that
this wasn’t the only intention of the malware. I’d be very surprised if there wasn’t a
DNS redirection payload involved. Hopefully someone will be able to dig out the payload
from the files and complete the picture.