What's wrong: New Linux Attack and Defense Technology

What's wrong: New Linux Attack and Defense Technology

 

The focus of any malware research is generally on where the expected attack may be targeted or where it is already under attack, so as to develop and implement new defense technologies. I reverse engineer some recent Linux malware samples and found an interesting new technology. I think it is very important and I want to share it with you. An attacker has logged on to a honeypot and tried to download files I have never seen before. Load the file to IDA Pro and get the prompt "SHT table size or offset is invalid. Continue? "This is normal for executable files, so there is no worries. However, after receiving this message, I receive a new warning that I have never seen before;

This causes the Linux Executable File ELF to fail to load in IDA Pro-prevents me from loading binary files for analysis. After opening the file from 010Editor using ELFTemplate, we can easily see what happened;

The header file of one program points out of the actual file. This is easy to solve. You only need to return to this part to allow IDA Pro to load the sample. Interestingly, it turns out that this is an invalid binary file, which is partially Misplaced because the file has been truncated. However, this error message directs me to download the path and tries to recreate the error file-this is simple. The hexadecimal editor is easy to implement;

Remove all parts from the ELF File Header

Find the program header that cannot be loaded by an ELF File

Causes this part of the program header to point out of the file.

IDA Pro cannot load any other file headers. After compiling a process into a script, I decided to use other anti-assembler and debugger to test several solutions. Radare (R2), Hopper, and lldb process no problem at all-but GDB does not recognize the file format;

Further analysis, I would like to see if it can be used as an anti-Analytical and anti-Fuzzy Technology, in addition to the disassembly technology. The idea at the time was that if I used several disassembly programs to find this problem easily, some anti-virus applications may have the same problem in their own parsing engines.

Here, I have captured a relatively complete malware sample from the Linux/XorDDos family;

Https://www.virustotal.com/en/file/0a9e6adcd53be776568f46c3f98e27b6869f63f9c356468f0d19f46be151c01a/analysis/

They just discovered that nine different engines (two from the same company? So I should say 10) the same malware cannot be detected. I am very interested in this because I am a newcomer to Linux malware. I would assume that these engines can easily detect malware and such a simple change will not be such a simple escape technology.

It seems that it is too easy to attack disassembly programs and engine monitoring-so I want to see the entire sample library to see if someone accidentally discovered and implemented this technology. Using the following simple YARA rule, I can find 6000 examples using this method. Fortunately, almost every of these examples is a commercial Android case that protects its own code.

Although we haven't seen any malicious behaviors that use this technology outside, there may be many other similar tricks outside. This is a good start. Look for and analyze ELF files that may be maliciously hidden. In the end, it is best to publish them using scripts so that people can monitor this technology and use similar technologies in the future.

In my previous article, I have notified Hex-Rays and the 10 engines that failed to detect slightly modified malware. The script code for generating and repairing these modified binary files can be found on github.

YARA rules: