Demonstrating Arcana ELF Infection Detection Capabilities

Introduction

In this article, we will look at the detection capabilities of Arcana, our comprehensive heuristic-based ELF infection-oriented detection engine. Arcana can detect common and not-so-common ELF infection techniques employed by advanced attackers for covertly running malware in the UNIX environment. For the sake of brevity, we won't consider all infection techniques for this demonstration. However, instead, we will focus on the most common ones and their novel permutations meant to increase stealth.

Our Setup

We will utilize d0zer, an ELF binary injector written in Golang, to generate infected ELF binaries with our desired ELF infection algorithms. D0zer can carry out Text Segment Padding, PT_NOTE infection, and Relative Relocation Poisoning to perform entry-point obfuscation and Shared Object Infection. D0zer has a built-in benign payload that prints out "Hello World -- this is a non-destructive payload," quickly allowing us to verify a working infection algorithm in the intended target. We will use a simple "Hello World" C program as our intended target binary. The infected target binary will then be subjected to Arcana's analysis engine so we can observe its detection capabilities.

Detection of PT_NOTE Infection

The infection algorithm "PT_NOTE to PT_LOAD" is quite popular because it is comparatively easy to implement and offers excellent versatility and flexibility. Potential ELF types of ET_DYN (dynamically linked) and ET_EXEC (statically linked) are viable for infection with arbitrarily sized payloads, removing constraints or worry around the size of the resident malware during development. In the image below, we infect our target "Hello World" C program with d0zer's benign payload using the PtNoteToPtLoad flag and opting for the default entry-point modification.

We then run Arcana to analyze the infected ELF binary.

Based on the output, Arcana detected that the ELF binary had its entry point modified to (0xc003c40) point to a location inside another segment not associated with the .text section.

This particular segment is not present in the original binary per se; it is the result of converting the PT_NOTE segment into a PT_LOAD segment,a central feature of the PT_NOTE Infection Algorithm. We can observe the change by running the readelf utility on the original binary (output below).

Detection of Relative Relocation Poisoning/Hijacking

For our next demo, we will investigate a relatively new technique called Relative Relocation Poisoning/Hijacking. In short, this technique utilizes relative relocation (R_X86_RELATIVE or R_X86_64_RELATIVE) record modification. The addend of the relocation record undergoes modification to point to the address of a malicious payload. Processing of Relative Relocations is the responsibility of the Dynamic Linker and Loader (ld-linux.so) during program initialization/startup. The Dynamic Linker will also execute constructor and deconstructor routines in .init_array and .fini_array, respectively, which in turn are patched via Relative Relocations in modern ELF binaries. Hijacking or Poisoning these relocation records allows for accomplishing two things: entry-point obscuration of a parasitic payload and enabling infection of shared objects (.so), where execution of the parasitic code would then occur within the address space of a binary dynamically linked against the infected shared object. Relative Relocation Poisoning/Hijacking is a powerful technique, so Arcana needs to be able to detect it.

Our target binaries will consist of a shared object (foo.c) that contains a function "foo()" that prints "Hello, I am a shared library."

Then, there is the source of the binary test program, dynamically linked against our shared object (foo.so) named "test."

Finally, we have "compile-lib.sh," while this isn't source code meant for compilation into an ELF binary, we provide it for transparency's sake.

Below, we will take note of the output of the uninfected test program.

Note the dependency or linkage to the shared object "libfoo.so" below.

We are ready to infect "libfoo.so" using d0zer to observe Arcana's capacity to detect Relative Relocation Hijacking/Poisoning in shared objects.

Based on the output of our test program, we can see that since it's linked against libfoo, the parasitic code or payload executes in the context of the test program.Finally, we get to test run Arcana to analyze libfoo, to see if the infection is detected.

Arcana flagged the binary based on the output as having its ctors (.init_array) modified and, along with the relocation itself, also having undergone alterations. Given the infection settings, these modifications align with what we can expect d0zer to apply to a binary. Modification of the relocation record was necessary for parasitic payload execution. However, the ctors modification was not. Not to make the modification obvious, d0zer reflected the change in the addend in the ctors or .init_array section; this is how it would be before infection. Arcana is "hip" to these anti-detection tricks and ensures the relocation record and .init_array are congruent and point to valid areas (.text section) within the binary, in this case both modifications resulted in the binary being flagged.

Conclusion

We should note that Arcana's detection capabilities in identifying infected ELF artifacts go beyond the things demonstrated in this article. The list of techniques, sub-techniques, and associated permutations is bountiful. However, by harnessing our research efforts and the community of ELF hackers, we encapsulated most of the offensive techniques and developed heuristic detection capabilities for them into Arcana.