Thursday, April 9, 2015

Deeper into the PE Header

Its been a bit, longer than I would have liked, since I posted.  Still, let's dive a bit deeper into the PE structure and get back to what we were doing.  Before I dig into PE sections, let's talk about a couple of integral concepts.  The first is about PE File Sections.  A section in a PE file equates to a segment or resources in an NE file. Sections are either code or data.  Text is considered data in this regard. So, effectively sections are just blocks of contiguous memory.  Sections can contain code or data that the program declared and uses directly or the sections might be built by a linker or compiler.  All that information about sections resides in a table, as directed by the COFF specification.  The Section Table contains the name of the section, permissions and size.

A couple of things bear review here.  The permission schema for sections is your standard read, write and execute.  While some compilers and linkers are more efficient than others, both employ an efficiency algorithm to influence the "grouping" of data.  They also try to keep section numbers low.

Again, that efficiency concept.  That translates to executable things being grouped together with other executable things into a section and the same for others types of permission requirements.  That doesn't mean you won't have 99 sections all marked executable, but it does mean that this kind of situation, just like its opposite of zero sections, is an outlier. So are these:

executable sections
common section names
section count
packers
zero byte section (null byte hash)
no sections named (rare)

Let's start with a few rules to tackle this (incomplete, not inclusive list of...) items.  Oh, and before we start can we just agree that, yes, you'll need to match for the file type you want as part of the condition.  Let's just skip that monotony at the moment.  If you don't know what I mean, go to gary kessler's site of file magic for "magic" values.

Let's play around with finding executable sections.  Its not uncommon for the data sections to have executable code.  Usually the text section isn't, however, and that might be useful to look for.  Since the "text" section is usually the first section, we would do it like this:

import "pe"

rule executable_code_in_text_section {
condition:
pe.sections[0].characteristics & SECTION_CNT_CODE
}

Of course, sections with executable code are different from sections that are executable:

import "pe"

rule executable_text_section {
condition:
pe.sections[0].characteristics & SECTION_MEM_EXECUTE
}

Of course, why all that's neat, it doesn't necessary solve any problems or help with detection.  However about this: by default, ALL packers need to have at least one section that is readable, writeable and executable.  That's something good worth detecting.  It also requires the latest version of Yara (3.3 as of this writing) to function.

import "pe"

rule read_write_execute {
condition:
pe.sections[0].characteristics & SECTION_MEM_EXECUTE and
pe.sections[0].characteristics & SECTION_MEM_READ and
pe.sections[0].characteristics & SECTION_MEM_WRITE
}

This is more arbitrary but also can work with some tuning (the choice of 500 accommodates most section headers...):
import "pe"
rule read_write_execute {
strings:
$b = {80 00 00 20}
condition:
pe.number_of_sections > 0 and $b in (0..500)
}

You can do a lot with the section characteristics.  Here's a good list from MSDN on characteristics but keep in mind when you contrast them with the yara documents on PE module, that they are similar but not identical.  The differences should be pretty straightforward to decipher, just sub in "section" for "IMAGE_SCN" and so on.

I'll just skip writing out all the packers you can capture with yara.  Here's a decent list to work from:  Packers in Yara

import "pe"

rule no_sections
{
   condition:
      pe.number_of_sections == 0
}

Suggestions for reading to understand entropy uses for detection and pattern analysis for detection.

http://www.security-assessment.com/files/presentations/Ruxcon_2006_-_Unpacking_Virus,_Trojans_and_Worms.pdf

No comments:

Post a Comment