Holiday Hack Yara Bypass

SANS Holiday Hack Yara Bypass


Recently I participated in the SANS Holiday Hack Challenge and one of the challenges that stood out to me had to due with editing a compiled C binary to bypass yara rules. Overall, it was a good challenge that took me around not too long to solve and helped me get back into doing cyber challenges because I have not done any in a while.

What even is Yara?

The official definition is a tool that malware researches sometimes use in order to help categorize samples of malware, but what exactly is it and how does it work? Essentially all it does is do pattern matching on a binary at runtime to validate if certain strings are within the binary and if all conditions are met the binary will not be ran, followed by an error message citing a yara rule. An example of a yara rule looks like:

rule silent_banker : banker
        description = "This is just an example"
        threat_level = 3
        in_the_wild = true

        $a = {6A 40 68 00 30 00 00 6A 14 8D 91}
        $b = {8D 4D B0 2B C1 83 C0 27 99 6A 4E 59 F7 F9}

        $a or $b or $c

What we can see here is examples of strings of hex bytes and ASCII strings being what will trigger the yara rule which stops the program from properly executing. There are many other types of yara rules and conditions that are available for use and I personally used to help me with understanding how they work.

Getting into the Challenge

Initial Recon

When initially engaging the challenge by interacting with the terminal you are presented with the following message:


This critical application is supposed to tell us the sweetness levels of our candy
manufacturing output (among other important things), but I can't get it to run.

It keeps saying something something yara. Can you take a look and see if you
can help get this application to bypass Sparkle Redberry's Yara scanner?

If we can identify the rule that is triggering, we might be able change the program
to bypass the scanner.

We have some tools on the system that might help us get this application going:
vim, emacs, nano, yara, and xxd

The children will be very disappointed if their candy won't even cause a single cavity.

After doing a quick ls to see what is actually on the system I saw one file and a folder: the_critical_elf_app, which seems to be the binary that the message was talking about and yara_rules, which contains the rules.yar file that needs to be bypassed. When running the binary it errors with the following message: yara_rule_135 ./the_critical_elf_app.

After opening the rules.yar file and going to Rule 135 I saw that it is simply checking for a string within the binary:

rule yara_rule_135 {
      description = "binaries - file Sugar_in_the_machinery"
      author = "Sparkle Redberry"
      reference = "North Pole Malware Research Lab"
      date = "1955-04-21"
      hash = "19ecaadb2159b566c39c999b0f860b4d8fc2824eb648e275f57a6dbceaf9b488"
      $s = "candycane"

The upper part can be ignored because it just contains metadata about the rule itself. Where it gets interesting is within the strings and condition parameters. Like I stated above all it is checking for is the string candycane and this is where I initally thought the challenge was going to be a walk in the park. Both fortunately and unfortunately, I was very wrong.

Initial Struggle / First Solve

After seeing this I immediately opened the file with vi and searched for the malicious string and figured that I could simply just remove the string with no other modification needed. When I initally did that and tried to run the binary again it seg faulted. For the longest time I had no idea why this was happening, possibly due to severe lack of sleep and energy drink crash, which prompted me to start to look for crash logs to see why this was happening.

It only occured to me after 15 minutes that the issue could be that I couldn’t just remove the string, but only had to REPLACE one character of the string because of how yara works. Once I figured this out I was able to replace one character of the string and get the program to properly execute…

Advanced? Vim / Second Solve

…until it failed another yara rule :(. This time it failed rule 1056 which is:

rule yara_rule_1056 {
        description = "binaries - file frosty.exe"
        author = "Sparkle Redberry"
        reference = "North Pole Malware Research Lab"
        date = "1955-04-21"
        hash = "b9b95f671e3d54318b3fd4db1ba3b813325fcef462070da163193d7acb5fcd03"
        $s1 = {6c 6962 632e 736f 2e36}
        $hs2 = {726f 6772 616d 2121}
        all of them

This one is a bit different than the first, not only does it provide two hex values rather than strings, but specifies that all the conditions have to be met for it to fail the rule.

This part also confused me because I thought I would have to find the hex code from something like xxd and then go into vim to change the string. This was until I found out about something really cool within vim: the ability to run shell commands when a file is open.

Doing this is really simple, all that needs to be done is to open the file in vim and then hit the colon and type %! xxd what this does is passes it through to xxd and allows you to edit the hex.

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0300 3e00 0100 0000 4010 0000 0000 0000  ..>.....@.......
00000020: 4000 0000 0000 0000 f039 0000 0000 0000  @........9......
00000030: 0000 0000 4000 3800 0d00 4000 1d00 1c00  ....@.8...@.....
00000040: 0600 0000 0400 0000 4000 0000 0000 0000  ........@.......
00000050: 4000 0000 0000 0000 4000 0000 0000 0000  @.......@.......

After doing this and searching for the first hex value it is shown that it points to a shared object so editing it will just break the program. The second value, however, is able to be changed.

00002050: 6973 2070 726f 6772 616d 2121 0000 0000  is program!!....

This line can be edited and after changing the hex string to something else it is able to run.

One thing to look out for is having to revert the file back from the xxd format. To do this simply just run %! xxd -r.

After the second solve another yara issue is thrown and this time with rule 1732. This rule isn’t very complex, but is just a lot of the same stuff that was done in the previous two rules. The only added part is the issues that arise with some of the strings occuring multiple times and wanting to simplify the process. The rule is:

rule yara_rule_1732 {
      description = "binaries - alwayz_winter.exe"
      author = "Santa"
      reference = "North Pole Malware Research Lab"
      date = "1955-04-22"
      hash = "c1e31a539898aab18f483d9e7b3c698ea45799e78bddc919a7dbebb1b40193a8"
      $s1 = "This is critical for the execution of this program!!" fullword ascii
      $s2 = "__frame_dummy_init_array_entry" fullword ascii
      $s3 = "" fullword ascii
      $s4 = ".eh_frame_hdr" fullword ascii
      $s5 = "__FRAME_END__" fullword ascii
      $s6 = "__GNU_EH_FRAME_HDR" fullword ascii
      $s7 = "frame_dummy" fullword ascii
      $s8 = "" fullword ascii
      $s9 = "completed.8060" fullword ascii
      $s10 = "_IO_stdin_used" fullword ascii
      $s11 = ".note.ABI-tag" fullword ascii
      $s12 = "naughty string" fullword ascii
      $s13 = "dastardly string" fullword ascii
      $s14 = "__do_global_dtors_aux_fini_array_entry" fullword ascii
      $s15 = "__libc_start_main@@GLIBC_2.2.5" fullword ascii
      $s16 = "GLIBC_2.2.5" fullword ascii
      $s17 = "its_a_holly_jolly_variable" fullword ascii
	  $s18 = "__cxa_finalize" fullword ascii
      $s19 = "HolidayHackChallenge{NotReallyAFlag}" fullword ascii
      $s20 = "__libc_csu_init" fullword ascii
      uint32(1) == 0x02464c45 and filesize < 50KB and
      10 of them

In the condition the first line can be ignored, but the second one is the one that matters. It says that 10 of the conditions need to be met for the program to bypass the rule.

Approach / Methodology

I first started off by identifying the strings that I knew would be save to remove. These are fairly self explanatory and are the ones that just say a message in them. After this 5 were able to be removed and the program was still able to properly execute (minus the yara violation).

After this I just used what I thought would be the standouts and wouldn’t occur more than once. This started with the strings that contained .note and after these were removed a few more had to be removed which was done with just trial and error.


Overall this was a really fun challenge and was more of a test of methodology than anything else. A lot of the contents of the challenge I doubt most people have experience with and it was designed to throw something new at us.