Analyzing a Linux malware binary

I encountered an interesting file in my honeypot a couple of days ago and it's not on virustotal or similar so I decided to take advantage of the situation a take a closer look myself.

Before going further let me tell you I'm not whatsoever a reversing expert, just a messy curious threat intel/threat hunting expert, and this article was a for-fun activity. I do like it and I wish I could properly do reversing! Someday, maybe.

The attacker uploaded the file through sftp:

Before anything else I used radare2 so to get some general info about the file:

rabin2 -I mymalware

And found out the following things:

arch     x86
baddr    0x400000
binsz    30048232
bintype  elf
bits     64
canary   false
injprot  false
class    ELF64
crypto   false
endian   little
havecode true
intrp    /lib64/ld-linux-x86-64.so.2
laddr    0x0
lang     c
linenum  false
lsyms    false
machine  AMD x86-64 architecture
nx       true
os       linux
pic      false
relocs   false
relro    partial
rpath    NONE
sanitize false
static   true
stripped true
subsys   linux
va       true

And:

rabin2 -Ir mymalware

e cfg.bigendian=false
e asm.bits=64
e asm.dwarf=true
e asm.codealign=1
e bin.lang=c
e file.type=elf
e asm.os=linux
e asm.arch=x86

So it's pretty clear that we are taking a look at a linux binary. Why is it interesting? What I usually find in my honeypot are IRC based miners, scripts for initial deployment and some keys, but this is slightly different.

I took a very quick look at the strings, and realized it used Golang. The file itself is stripped, as I realized when using >afl | head -n20 (just 20 lines so to take a look) even when using a pipe with redress.

This didn't stop me. I took a quick look around. I used binwalk and `strings. I proceeded to note down some general clear ideas:

• It uses Golang
• It's an elf for AMD x86-64 architecture

Anyway I tried to look for executable paths and exfiltration traces or maybe C2, since those are the common things found in bots or maybe stealers. I have a bunch of key-words that help me dive through these sort of things, and I found a suspicious hardcoded IP in /etc/services:


100.64.0[.]0

Using a really quick search over VT, it revealed a pulse related with GoScanSSH family, which pretty much fits in this situation.

I keep searching:

Realized that it also tries to identify the IP using some legit IP info services online, such as


http://ipgrab[.]io
https://ident[.]me
https://ip.seeip[.]org
http://inet-ip[.]info


And saves it all into a zip file. I wondered where did it meant to send it and I found a hardcoded discord api location, so that must be it, since discord (as well as Telegram) is currently being used a lot for exfiltration.

Then I found some command lines (for example chmod attempts, but not for example chattr or ulimit, which usually goes together in regular miner families) that grabbed my attention:


service systemd-worker enable || systemctl enable systemd-worker.service


Basically because that "systemd-worker" thing sounded familiar. I remember reading about this before so a quick search and yep! It reminded my of Panchan.

"(...)Finally, the malware executes the binary and initiates an HTTPS POST operation to a Discord webhook, which is likely used for monitoring the victim.

To establish persistence, the malware copies itself to `/bin/systemd-worker and creates a new systemd service to launch after reboot while masquerading as a legitimate system service.(..)"

it adds up.

This definitely rang a bell and looked for some more info about it and I found some "look and destroy"-like (as I like to call it) function:

current_preset_xmrig_enabled *bool; current_preset_xmrig_nicehash

Yeah this totally looked like Panchan. And, according to Bleeping Computer:

"The malware also features an anti-kill system that detects process termination signals and ignores them unless it's SIGKILL which isn't handled."

I also saw this before going around, so I rechecked:

SIGKILL: kill
SIGQUIT: quit

And... yeah after reading the article that akamai I saw this:

If you are wondering: yes, I checked previously with an automated genetic analysis and static analysis vendors, but it wasn't very helpful and didn't point me to the actual threat (mostly because it was corrupted, but that doesn't mean it doesn't have information in it!).

Anyway this has been fun. I totally have to sharpen my reversing abilities so to make this "the proper way" and not "string | grep" it.

You can check the IoCs in my AlienVault pulse!
If you want to read the japanese version, check here
日本語の記事はここにです