Example to Detect Malicious ELF Binaries (Linux Encoder Ransomware)

[rcole]

Good afternoon!

We've got another sample of what can be accomplished using our custom signature engine today. Please note before continuing that:

A) This signature exists as a sample to show what is possible, and has not been properly QA'd/soak tested to ensure no false positives. The hex values from the binaries were arbitrarily chosen simply to show how the process works, and were not analyzed against known legitimate ELF binaries for collision testing.

B) Please read A! Please. 🙂

The purpose of this signature is to detect malicious ELF binaries that belong to a family of ransomware dubbed "Linux Encoder," which is targeting web servers, encrypting their files, and shaking down the owners for money.

Intelligence showed five known samples of the malware in the wild, with SHA1 hashes of:

a5054babc853ec280f70a06cb090e05259ca1aa7
98e057a4755e89fbfda043eaca1ab072674a3154
810806c3967e03f2fa2b9223d24ee0e3d42209d3
12df5d886d43236582b57d036f84f078c15a14b0
5bd6b41aa29bd5ea1424a31dadd7c1cfb3e09616

Grabbing these samples and doing a hex dump, we look for (what we hope) are unique values in the hex dump. We grab those values, and we head into our lab firewall to make a signature.

A single AND condition with five nested OR conditions, using pattern matching within the file-elf-body context, and a pattern containig \x(hexhere)\x.

We set the action to reset-both, and we commit the signature.

We attempt to transfer the files, and watch the signature trigger, denying the transfer.

I've attached the sample signature for review.

To be more accurate in the future, one thing that could be done would be ensure that the values pulled from the hex dumps are unique to the samples, and don't contain values that may be shared with other ELF binaries that are not malicious. This requires a bit more finesse and a good understanding of the ELF file structure/unique qualities of the malicious samples. Those who would like to enjoy a journey into RFCs/Wiki articles to ensure their signature is fail proof are welcomed to do so!

I will attempt to get more detailed in my next description, but the above should suffice as a simple framework for how signatures can be created to stop transfer of file types over the wire.

Note that we also have file contexts for (not all inclusive, see the document in the sticky):

FLV, HTML, Java, MOV, Office, PDF, RIFF, SWF, TIFF, and "unknown."

The signature has been attached for your perusal.